Este es un controlador bastante completo para las GPU de las series Apple AGX G13 y G14.
El controlador de hoy es compatible con los SoC

Se dio a conocer hace poco la noticia de que se ha propuesto una implementación preliminar del controlador drm-asahi para las GPU de las series Apple AGX G13 y G14 utilizadas en los chips Apple M1 y M2 en la lista de correo de desarrolladores del kernel de Linux.

El controlador está escrito en Rust y, además, incluye un conjunto de enlaces universales sobre el subsistema DRM (Direct Rendering Manager) que se puede usar para desarrollar otros controladores de gráficos en Rust.

El conjunto de parches publicado hasta ahora se ha propuesto solo para su discusión por parte de los desarrolladores principales (RFC), pero puede aceptarse en el equipo principal después de que se complete la revisión y se eliminen las deficiencias identificadas.

Esta es mi primera versión de las abstracciones de Rust para el DRM subsistema. Incluye las propias abstracciones, algunas menores cambios de requisitos previos en el lado C, así como el controlador de GPU drm-asahi (para referencia sobre cómo se usan las abstracciones, pero no necesariamente destinados a aterrizar juntos).

Estos parches se aplican en la parte superior del árbol en [1], que se basa en 6.3-rc1 con una gran cantidad de compromisos de abstracción/soporte de Rust agregados en arriba. La mayoría de estos no son requisitos previos para las abstracciones de DRM. ellos mismos, sino sólo del conductor.

Desde diciembre, el controlador se incluye en el paquete con el kernel para la distribución de Asahi Linux y ha sido probado por los usuarios de este proyecto.

El controlador se puede utilizar en distribuciones de Linux para organizar el entorno gráfico en dispositivos Apple con SoC M1, M1 Pro, M1 Max, M1 Ultra y M2. Al desarrollar el controlador, se intentó no solo aumentar la seguridad al minimizar los errores al trabajar con la memoria en el código ejecutado en el lado de la CPU, sino también proteger parcialmente contra los problemas que surgen al interactuar con el firmware.

En particular, el controlador proporciona ciertos enlaces para estructuras de memoria compartida no seguras con cadenas complejas de punteros utilizados en el firmware para interactuar con el controlador. El controlador propuesto se usa junto con el controlador asahi Mesa, que brinda compatibilidad con OpenGL en el espacio del usuario y pasa las pruebas de compatibilidad con OpenGL ES 2 y está casi listo para admitir OpenGL ES 3.0.

Al mismo tiempo, el controlador que funciona a nivel de kernel se desarrolla inicialmente teniendo en cuenta el soporte futuro para la API de Vulkan, y la interfaz de programación para interactuar con el espacio del usuario se diseña teniendo en cuenta la UAPI proporcionada por el nuevo controlador Intel Xe.

Sobre los problemas conocidos se mencionan los siguientes:

• La integración de Rust existente actualmente no permite construir abstracciones como módulos, por lo que las abstracciones de Rust solo están disponibles para los componentes DRM integrados.
• DRM se basa en gran medida en el patrón de “subclases” para objetos de controlador, y esto no se corresponde bien con Rust.
• Actualmente, solo se implementa lo necesario para el controlador (más una pequeña cantidad de
  extras obvios donde tiene sentido una mejor integridad de la API).
• drm::mm termina requiriendo un mutex incorporado en la abstracción, en su lugar
  de delegar eso al usuario con las reglas habituales de mutabilidad de Rust.
  Esto se debe a que los nodos se pueden descartar en cualquier momento y esas operaciones
  necesita estar sincronizado.
• En el lado de Mesa, actualmente se cuenta con el controlador Gallium que en su mayoría ya está aguas arriba (faltan los bits UAPI en su mayoría) y
  pasa las pruebas dEQP GLES2/EGL, con la mayor parte de GLES3.0 pasando en
  Ramas upstream de trabajo en curso. Esta es una ingeniería inversa controlador comunitario, por lo que se menciona que aún queda mucho por hacer en este aspecto.

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/dZt5XiO
via IFTTT

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer la noticia de que han identificado dos vulnerabilidades (ya catalogadas bajo CVE-2023-1017, CVE-2023-1018) en el código con la implementación de referencia de la especificación TPM 2.0 (Trusted Platform Module).

Los fallos detectados son destacables, ya que estos llevan a escribir o leer datos fuera de los límites del búfer asignado. Un ataque a implementaciones de criptoprocesadores que utilicen código vulnerable podría resultar en la extracción o sobrescritura de información almacenada en el lado del chip, como claves criptográficas.

Un atacante que tenga acceso a una interfaz de comando TPM puede enviar comandos creados con fines malintencionados al módulo y desencadenar estas vulnerabilidades. Esto permite el acceso de solo lectura a datos confidenciales o la sobrescritura de datos normalmente protegidos que solo están disponibles para el TPM (por ejemplo, claves criptográficas).

Se menciona que un atacante puede usar la capacidad de sobrescribir datos en el firmware de TPM para organizar la ejecución de su código en el contexto de TPM, que, por ejemplo, puede usarse para implementar backdoors que funcionan en el lado de TPM y no se detectan desde el Sistema operativo.

Para quienes desconocen de TPM (Trusted Platform Module), deben saber que esta es una solución basada en hardware que proporciona funciones criptográficas seguras a los sistemas operativos de las computadoras modernas, haciéndolo resistente a la manipulación.

Un atacante local autenticado podría enviar comandos malintencionados a un TPM vulnerable que permita el acceso a datos confidenciales. En algunos casos, el atacante también puede sobrescribir datos protegidos en el firmware de TPM. Esto puede provocar un bloqueo o la ejecución de código arbitrario dentro del TPM. Debido a que la carga útil del atacante se ejecuta dentro del TPM, es posible que otros componentes del dispositivo de destino no la detecten.

A medida que la computación en la nube y la virtualización se han vuelto más populares en los últimos años, las implementaciones de TPM basadas en software también han ganado popularidad. El TPM se puede implementar en forma de TPM discreto, integrado o de firmware en su forma de hardware. Los TPM virtuales existen en forma de hipervisor o en una implementación de TPM puramente basada en software, por ejemplo, swtpm.

Sobre las vulnerabilidades detectadas, se menciona que estas son causadas por una verificación de tamaño incorrecto de los parámetros de la función CryptParameterDecryption(), que permite escribir o leer dos bytes fuera del búfer pasado a la función ExecuteCommand() y que contiene el comando TPM2.0. Según la implementación del firmware, la sobrescritura de dos bytes puede corromper tanto la memoria no utilizada como los datos o punteros en la pila.

La vulnerabilidad se aprovecha mediante el envío de comandos especialmente diseñados al módulo TPM (el atacante debe tener acceso a la interfaz TPM).

Actualmente, los problemas ya fueron solucionados mediante el envió de las versiones de actualización de la especificación TPM 2.0 publicada en enero (1.59 Errata 1.4, 1.38 Errata 1.13, 1.16 Errata 1.6).

Por otra parte, tambien se informa que la biblioteca de código abierto libtpms, que se utiliza para emular mediante programación los módulos TPM e integrar la compatibilidad con TPM en los hipervisores, también se ve afectada por la vulnerabilidad. Aunque tambien es importante mencionar que la vulnerabilidad se corrigió en el lanzamiento de libtpms 0.9.6, por lo que para aquellos que estén en una versión anterior, se recomienda que actualizan a la nueva versión lo antes posible.

Sobre la solución a estos fallos, TCG (Trusted Computing Group) ha publicado una actualización de su Errata para la especificación de la biblioteca TPM2.0 con instrucciones para abordar estas vulnerabilidades. Para garantizar la seguridad de sus sistemas, los usuarios deben aplicar las actualizaciones proporcionadas por los fabricantes de hardware y software a través de su cadena de suministro lo antes posible.

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/P2SFIT9
via IFTTT

El navegador Chrome se diferencia de Chromium en el uso de los logotipos de Google

Google dio a conocer recientemente el lanzamiento de la nueva versión de su navegador web Google Chrome 111, en la cual se han realizado diversos cambios y mejoras internos. Además de las innovaciones y la corrección de errores, se han corregido 40 vulnerabilidades en la nueva versión.

Como parte del programa de pago de recompensas en efectivo por el descubrimiento de vulnerabilidades para la versión actual, Google pagó 24 premios por un monto de 92 mil dólares estadounidenses (un premio de $15 000 y $4000, dos premios de $10 000 y $700, tres premios de $5,000, $2,000 y $1,000, cinco premios de $3,000).

Principales novedades de Chrome 111

En esta nueva versión que se presenta de Chrome 111, se actualizaron los elementos de la interfaz relacionados con la iniciativa Privacy Sandbox para permitir que se definan y utilicen categorías de intereses de los usuarios en lugar de rastrear cookies para resaltar grupos de usuarios con intereses similares sin identificar a usuarios individuales. La nueva versión agrega un nuevo cuadro de diálogo que informa a los usuarios sobre las funciones de Privacy Sandbox y redirige a la página de configuración, donde puede configurar la información enviada a las redes publicitarias.

Otro de los cambios que se destaca de la nueva versión de Chrome 111, es que en Linux y Android, las operaciones de resolución de nombres en DNS se trasladan de un proceso de red aislado a un proceso de navegador no aislado, ya que cuando se trabaja con un sistema de resolución, es imposible implementar algunas restricciones de sandbox que se aplican a otros servicios de red.

Ademas de ello, tambien podremos encontrar que se agregó una API de imagen en imagen de documento experimental (prueba de origen) para abrir contenido HTML arbitrario en modo de imagen en imagen, no solo video. A diferencia de abrir una ventana a través de una llamada a window.open(), las ventanas creadas a través de la nueva API siempre se muestran encima de otras ventanas, no permanecen después de que se cierra la ventana original, no admiten la navegación y no pueden determinar explícitamente la posición.

El uso de la API del controlador de pagos, que simplifica la integración con los sistemas de pago existentes, ahora requiere una definición explícita de la fuente de los datos descargados mediante la especificación de los dominios a los que se envían las solicitudes en el parámetro CSP connect-src (Content-Security-Policy).

Se agregó compatibilidad para que los usuarios inicien sesión automáticamente en los servicios de identidad de Microsoft (Azure AD SSO) utilizando la información de la cuenta de Microsoft Windows, ademas de que el mecanismo de actualización de Chrome en Windows y macOS gestiona las actualizaciones de las últimas 12 versiones del navegador.

De los demás cambios que se destacan:

• Se ha propuesto un nuevo cuadro de diálogo con información sobre cómo habilitar la capacidad de sincronizar configuraciones, historial, marcadores, bases de datos de autocompletado y otros datos entre navegadores.
• Proporcionó la capacidad de aumentar o disminuir el tamaño de ArrayBuffer, así como aumentar el tamaño de SharedArrayBuffer.
• WebRTC implementa soporte para extensiones SVC (Scalable Video Coding) para adaptar un flujo de video al ancho de banda del cliente y transmitir varios flujos de video de diferente calidad en un solo flujo.
• Las acciones «diapositiva anterior» y «diapositiva siguiente» se agregaron a la API de sesión de medios para organizar la navegación entre las diapositivas anterior y siguiente.
• Se agregó una nueva sintaxis para las pseudoclases «:nth-child(an + b)» y «:nth-last-child()» para permitir obtener un selector para filtrar previamente los elementos secundarios antes de realizar la selección principal «An+B «.
  Se han realizado mejoras en las herramientas para desarrolladores web.
• Se ha agregado compatibilidad con la especificación CSS Color Level 4 y sus nuevos espacios de color y paletas al panel Estilos.
• La compatibilidad con nuevos espacios de color y la capacidad de convertir entre diferentes formatos de color se ha agregado a la herramienta para determinar el color de píxeles arbitrarios («cuentagotas»).
• El depurador de JavaScript tiene un panel de control de punto de interrupción rediseñado.

¿Como instalar Google Chrome 111 en Linux?

Si estás interesado en poder instalar esta nueva versión de este navegador web y aún no lo tienes instalado, puedes visitar la siguiente publicación en donde te enseñamos a como poder instalarlo en algunas distribuciones de Linux.

El enlace es este. 

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