Hace pocos dias se dio a conocer la noticia de que investigadores de la Universidad Ben-Gurion (Israel), la Universidad de Lille (Francia) y la Universidad de Adelaide (Australia) han desarrollado una nueva técnica para identificar los dispositivos de los usuarios mediante la detección de parámetros GPU en un navegador web.

El método se llama «Drawn Apart» y se basa en el uso de WebGL para obtener un perfil de rendimiento de GPU, lo que puede mejorar significativamente la precisión de los métodos de seguimiento pasivo que funcionan sin usar cookies y sin almacenar un identificador en el sistema del usuario.

Los métodos que tienen en cuenta las características de representación, GPU, pila de gráficos y controladores al identificarlos se usaron anteriormente, pero estaban limitados a la posibilidad de separar dispositivos solo al nivel de diferentes modelos de tarjetas de video y GPU, es decir solo podría usarse como un factor adicional para aumentar la probabilidad de identificación.

La característica clave del nuevo método «Drawn Apart» es que no se limita a separar diferentes modelos de GPU, sino que trata de identificar las diferencias entre GPU idénticas del mismo modelo, debido a la heterogeneidad del proceso de producción de chips diseñados.

Tambien se menciona que se observan que las variaciones que ocurren durante el proceso de producción hacen posible formar moldes no repetitivos para los mismos modelos de dispositivos.

Resultó que estas diferencias se pueden identificar contando el número de unidades de ejecución y analizando su rendimiento en la GPU. Como primitivas para identificar diferentes modelos de GPU, se utilizaron comprobaciones basadas en un conjunto de funciones trigonométricas, operaciones lógicas y cálculos de punto flotante. Para identificar las diferencias en la misma GPU, se estimó la cantidad de subprocesos que se ejecutan simultáneamente al ejecutar sombreadores de vértices.

Se supone que el efecto revelado es causado por las diferencias en los regímenes de temperatura y el consumo de energía de diferentes instancias de chip (anteriormente se demostró un efecto similar para la CPU: los mismos procesadores demostraron un consumo de energía diferente al ejecutar el mismo código).

Dado que las operaciones a través de WebGL son asíncronas, no se puede utilizar directamente la API de JavaScript performance.now() para medir su tiempo de ejecución, por lo que se propusieron tres trucos para medir el tiempo:

• En pantalla: representación de la escena en el lienzo HTML con la medición del tiempo de respuesta de la función de devolución de llamada expuesta a través de la API Window.requestAnimationFrame y llamada después de que se complete la representación.
• Fuera de pantalla: usar un trabajador y representar la escena en un objeto OffscreenCanvas midiendo el tiempo de ejecución del comando convertToBlob.
• GPU: representación en un objeto OffscreenCanvas, pero con un temporizador proporcionado por WebGL para medir el tiempo, teniendo en cuenta la duración de la ejecución de un conjunto de comandos en el lado de la GPU.

En el proceso de creación de un identificador se realizan 50 comprobaciones en cada dispositivo, cada una de las cuales cubre 176 medidas de 16 características diferentes. El experimento, durante el cual se recopiló información en 2500 dispositivos con 1605 GPU diferentes, mostró un aumento del 67% en la eficiencia de los métodos de identificación combinados al agregarles soporte Drawn Apart.

En particular, el método combinado FP-STALKER, en promedio, proporcionó identificación dentro de los 17,5 días, y en combinación con Drawn Apart, la duración de la identificación aumentó a 28 días.

Se observa que la precisión se vio afectada por la temperatura de la GPU y, para algunos dispositivos, reiniciar el sistema provocó una distorsión del identificador. Cuando se usa el método en combinación con otros métodos de identificación indirecta, la precisión puede incrementarse significativamente. También se planea aumentar la precisión mediante el uso de sombreadores de cómputo después de la estabilización de la nueva API WebGPU .

Intel, ARM, Google, Khronos, Mozilla y Brave fueron notificados del problema ya en 2020, pero los detalles del método acaban de ser revelados.

Entre otras cosas, los investigadores publicaron ejemplos de trabajo escritos en JavaScript y GLSL que pueden funcionar con y sin mostrar información en la pantalla. También para sistemas basados ​​en GPU Intel GEN 3/4/8/10, se han publicado conjuntos de datos para clasificar la información extraída en sistemas de aprendizaje automático.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/zya1jS5
via IFTTT

Amazon dio a conocer el lanzamiento de Firecracker 1.0, el cual es un monitor de máquina virtual (VMM, Virtual Machine Monitor), diseñado para ejecutar máquinas virtuales con una sobrecarga mínima. Firecracker es una bifurcación del proyecto CrosVM utilizado por Google para ejecutar aplicaciones de Linux y Android en ChromeOS.

Amazon Web Services está desarrollando Firecracker para mejorar el rendimiento y la eficiencia de las plataformas AWS Lambda y AWS Fargate.

Sobre Firecracker

Para quienes desconocen de Firecracker, deben saber que este ofrece máquinas virtuales livianas llamadas microVM. El aislamiento completo de microVM utiliza tecnologías de virtualización de hardware basadas en el hipervisor KVM, al mismo tiempo que mantiene el rendimiento y la flexibilidad de los contenedores convencionales.

El sistema está disponible para arquitecturas x86_64 y ARM64 y ha sido probado en las familias de CPU Intel Skylake, Intel Cascade Lake, AMD Zen2 y ARM64 Neoverse N1, ademas de que se proporcionan herramientas para integrar Firecracker en el tiempo de ejecución de los sistemas de aislamiento de contenedores, como Kata Containers, Weaveworks Ignite y containerd (proporcionado por firecracker-containerd runtime).

El entorno de software que se ejecuta dentro de las máquinas virtuales se ha truncado y contiene solo un conjunto mínimo de componentes. Para ahorrar memoria, reducir el tiempo de inicio y mejorar la seguridad en los entornos, se lanza un kernel de Linux simplificado (en el cual se admiten los kernels 4.14 y 5.10), del que se excluye todo lo innecesario, incluida la funcionalidad reducida y la compatibilidad con dispositivos eliminados.

Cuando se ejecuta con un kernel truncado, el consumo de memoria adicional en comparación con un contenedor es inferior a 5 MB. La latencia desde el inicio de la microVM hasta el inicio de la ejecución de la aplicación se establece entre 6 y 60 ms (promedio de 12 ms), lo que permite generar nuevas máquinas virtuales a hasta 180 entornos por segundo en un host con 36 nucleos.

Para administrar entornos virtuales de espacio de usuario, se ejecuta el proceso en segundo plano Virtual Machine Manager, que proporciona una API RESTful que implementa funciones como configurar, iniciar y detener microVM, seleccionar plantillas de CPU (C3 o T2), determinar la cantidad de procesadores virtuales ( vCPU) y el tamaño de la memoria, agregando interfaces de red y particiones de disco, estableciendo límites en el ancho de banda y la intensidad de las operaciones, proporcionando memoria adicional y potencia de CPU en caso de escasez de recursos.

Firecracker es utilizado por/integrado con: appfleet, containerd via firecracker-containerd, Fly.io, Kata Containers, Koyeb, Northflank, OpenNebula, Qovery, UniK y Weave FireKube.

Además de ser utilizado como una capa de aislamiento más profunda para contenedores, Firecracker también es adecuado para proporcionar sistemas FaaS (Function as a Service), que ofrecen un modelo de computación sin servidor, en el que el desarrollo se lleva a cabo a nivel de preparación de un conjunto de pequeños funciones individuales, cada una de las cuales proporciona el procesamiento de un determinado evento y está diseñada para una operación independiente sin referencia al entorno (sin estado, el resultado no depende del estado anterior y el contenido del sistema de archivos).

Las funciones se ejecutan solo cuando es necesario e inmediatamente después de que se procesa el evento, completan su trabajo. La propia plataforma FaaS alberga funciones aprovisionadas, organiza la gestión y proporciona la escalabilidad de los entornos necesarios para ejecutar las funciones aprovisionadas.

¿Como compilar firecracker en Linux?

Para los que estén interesados en poder probar firecracker en su sistema, pueden realizar la compilación de este por su cuenta.

Para ello basta con que solo abran una terminal y lo primero que deben hacer es obtener el código fuente para poder realizar la compilación, esto lo pueden hacer tecleando:

git clone https://github.com/firecracker-microvm/firecracker

Hecho esto podremos entrar a la carpeta de firecracker con:
cd firecracker

Y procedemos a realizar la compilación con:

tools/devtool build
toolchain="$(uname -m)-unknown-linux-musl"

Finalmente si estás interesado en poder conocer más al respecto sobre Firecracker, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/K9hONLb
via IFTTT