Google tenía razón con su código rojo: Bing supera los 100M de usuarios al día tras integrar ChatGPT

chatgpt-bing

Microsoft quiere poner a temblar a Google implementando chatgpt en bing

Durante las últimas semanas, y lo que le queda, se está hablando mucho sobre ChatGPT. La mayoría de los artículos son para elogiarlo, aunque también hay otros para intentar bajar un poco el hype, pero está en boca de todos. Quien no lo ha mencionado nunca (que yo sepa) directamente ha sido Google, pero sí se rumorea que internamente habían activado el código rojo. Por lo que parece, no exageraban, ya que la gente ha empezado a usar Bing y Edge más que nunca.

Lo de Edge no extraña tanto. En realidad, es un Chrome con personalizaciones de Microsoft que se integra mejor en el sistema operativo. Lo de Bing sí sorprende un poco más, y es que la compañía dice que ya han superado los 100M de usuarios activos al día. Esa cantidad puede parecer irrisoria si tenemos en cuenta que Google es usado por prácticamente todos los que tienen acceso a un navegador web, pero es que el aumento llega desde un uso muy bajo.

¿Despegará por fin Bing?

Nos complace anunciar que, tras varios años de progreso constante, y con el impulso de los más de un millón de nuevos usuarios de la vista previa de Bing, hemos superado los 100 millones de usuarios activos diarios de Bing. Se trata de una cifra sorprendentemente notable, aunque somos plenamente conscientes de que seguimos siendo una pequeña empresa con una cuota de un solo dígito. Dicho esto, ¡qué bien sienta estar en el baile!

El salto aún parece mayor cuando se conoce un detalle: actualmente, los usuarios de iOS/iPadOS, Android, macOS, Linux y cualquier otro sistema operativo estamos aún en una lista de espera. Para adelantarnos en la cola, tenemos que usar Microsoft Edge en un Windows con la configuración recomendada por el sistema operativo, que básicamente es tener Edge como navegador por defecto. Por lo tanto, esa cifra sólo puede aumentar en las próximas semanas, cuando los usuarios de equipos con otras configuraciones puedan acceder al servicio.

Y todo esto ha pasado en sólo un mes. De todos los nuevos usuarios, el 30% son completamente nuevos en Bing, y el número de búsquedas también está aumentando. Por si esto fuera poco, también están viendo como el nuevo Bing se está usando más en teléfonos móviles.

Ahora queda por ver qué hace Google. Está trabajando en su propio chatbot, y es difícil imaginar una web en la que las búsquedas no estén dominadas o en posesión de Google, pero todo es posible. Y como no se den prisa, el código rojo pasará a ser un Defcon X.

Más información.

from Linux Adictos https://ift.tt/5xGKwOS
via IFTTT

Proponen la implementación de un controlador GPU escrito en Rust, para las Apple AGX G13 y G14

Linux Apple Rust

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

Detectaron 2 vulnerabilidades en TPM 2.0 que permiten el acceso a datos 

vulnerabilidad

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