Banner de Fedora 40 beta

Los desarrolladores del proyecto Fedora, dieron a conocer la liberación de la versión beta de Fedora 40, y en ella nos presentan los cambios y mejoras en los que trabajaron para la versión estable, ya que esta versión beta marcó la transición a la etapa final de prueba, durante la cual solo se corrigen los errores críticos.

En esta beta de Fedora 40 podremos encontrar una gran cantidad de cambios, actualizaciones, correcciones, asi como también una serie de novedades que van enfocadas hacia Wayland tanto en el entorno de escritorio Gnome 46 como en KDE Plasma 6.

Principales novedades de Fedora 40 Beta

La versión beta de Fedora 40 presenta él entorno de escritorio Gnome 46 con GTK 4.13 y libadwaita 1.4.2. De los cambios significativos se destacan los realizados en Nautilus donde se implementó la solución a un problema de rendimiento de larga data al cambiar entre vistas, como de lista a cuadrícula. Anteriormente, Nautilus intentaba recargar todo el directorio cada vez que se cambiaba la vista, lo que provocaba un impacto negativo en la velocidad y la eficiencia del proceso.

Además, la función de búsqueda de Nautilus ha sido completamente revisada en GNOME 46. Se han introducido dos tipos de búsqueda:

1. Buscar en la carpeta actual: Esta función reemplaza al botón de búsqueda original y se centra en buscar archivos dentro del directorio que se muestra actualmente. Esto mejora la experiencia de búsqueda al permitir buscar archivos dentro de un contexto específico.
2. Búsqueda global: Se ha añadido un nuevo botón en el panel izquierdo que permite buscar instantáneamente en todo el sistema de archivos los archivos deseados. Esta función facilita la localización de archivos en todo el sistema de manera eficiente.

En la edición de escritorio KDE se ha actualizado a la versión KDE 6, la cual utiliza el protocolo Wayland y se ha suspendido la compatibilidad con sesiones basadas en X11, y el servidor XWayland DDX se utiliza para ejecutar aplicaciones X11 en una sesión basada en Wayland. Varios factores contribuyeron a esta transición, como la sustitución de los controladores fbdev en Fedora 36 por el controlador simpledrm, que es compatible con Wayland, y el soporte de Wayland en los controladores propietarios de NVIDIA.

En cuanto a las distribuciones personalizadas actualizadas atómicamente desarrolladas por el proyecto Fedora, se han unido bajo la marca Atomic Desktops, donde las primeras compilaciones conservan sus nombres anteriores, mientras que las nuevas versiones de Fedora Sericea y Fedora Onyx ahora se distribuyen bajo los nombres Fedora Sway Atomic y Fedora Budgie Atomic.

De los de más cambios que se destacan:

• Habilitación de un mecanismo para determinar conflictos de direcciones IPv4 en la red local en NetworkManager.
• Cambio a DNF 5 para instalar dependencias de compilación en Mock, Koji y Copr.
• Deshabilitación de la carga de metadatos con listas de archivos en DNF de forma predeterminada.
• Eliminación del paquete OpenSSL 1.1 y migración a OpenSSL 3.0, eliminación del paquete python3.7.
• Reemplazo de la biblioteca Zlib por Zlib-ng para mejorar el rendimiento.
• Detención de la generación de actualizaciones delta de paquetes RPM y deshabilitación de la compatibilidad con Deltarpm en DNF y DNF5.
• Agregado de Passim, un servidor de caché para distribuir archivos solicitados frecuentemente en la red local sin involucrar servidores principales ni CDN globales.
• El módulo pam_userdb ha migrado de BerkeleyDB a GDBM debido a la obsolescencia de la rama BerkeleyDB 5.x y a la inaceptable licencia de la rama BerkeleyDB 6.x. También, Bogofilter ha adoptado SQLite en lugar de BerkeleyDB (libdb).
• Se utiliza el kit de herramientas Image Builder para crear imágenes de Fedora Workstation Live, permitiendo compilaciones repetibles y personalización simplificada.
• El kit de herramientas osbuild se emplea para crear imágenes mínimas en la arquitectura ARM.
• Se ha cambiado a Kiwi en lugar de ImageFactory para generar imágenes de Fedora Cloud Edition.
• Se ha reestructurado el paquete para Kubernetes.
• Se está trabajando para incluir una versión más nueva del estándar de lenguaje C en GCC de forma predeterminada.
• Se ha completado la segunda etapa de la transición al proceso de carga modernizado propuesto por Lennart Pöttering, que implica el uso de una imagen UKI para cargar el kernel desde UEFI de forma segura y verificada.
• Se ha agregado un paquete listo para usar con PyTorch en el repositorio, disponible para instalación con el comando «dnf install pytorch», con planes futuros para agregar soporte de GPU y aceleradores NPU.

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

Descargar y obtener la beta de Fedora 40

Para los interesados en descargar la beta de Fedora 40 para instalar o probar en sus equipos, pueden obtener la imagen del sistema con Gnome o sus diferentes variantes (Spins) desde el sitio web oficial de la distribucion. El enlace es este.

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

Cuatro meses después de la última actualización mayor (4.0) y una seis semanas después de la versión beta, Blender Foundation ha lanzado por fin Blender 4.1. Como ya sabíamos, en esta actualización se ha añadido soporte para las APU AMD Ryzen basadas en RDNA3 y se ha mejorado el rendimiento el usar el popular software de modelado 3D, entre otras cosas, bajo Linux, alrededor de un 5% más rápido al renderizar los proyectos y exportarlos a un archivo final.

Otra novedad para los usuarios de Linux, o debería decir Unix, ya que también se usa en BSD, es que Blender 4.1 en Wayland ahora soporta editores de métodos de entrada. Lo que tenéis a continuación es una lista resumida con algunas novedades que han llegado junto a esta versión.

Novedades más destacadas de Blender 4.1

• Aceleración de Open Image Denoise para GPUs NVIDIA, Intel y Apple Silicon.
• El renderizado en CPU Linux es un 5% más rápido que en versiones anteriores.
• Soporte de renderizado de GPU AMD para APUs RDNA3.
• El compositor de vista ahora soporta los nodos Vector Blur, Defocus, Cryptomatte y Keying Screen.
• Mejoras en los nodos de geometría.
• El soporte de Blender Hydra ahora maneja el renderizado de pelo del sistema de partículas, soporte mejorado para la conversión de shaders a MaterialX, y la exportación de mallas grandes ahora es paralelizada.

Para conocer más detalles, podéis leer el artículo publicado por mi compañero Darkcrizt el pasado febrero, y también visitar las notas oficiales de este lanzamiento. Blender 4.1 se anunció en la tarde del martes 26 de marzo, y su tarball ya se puede descargar desde el siguiente botón. Su paquete snap ya está actualizado, y en las próximas horas deberían hacer lo propio con su versión flatpak. Ya mas adelante llegará a los repositorios oficiales de algunas distribuciones Linux. La siguiente versión será Blender 4.2 y debería llegar en un plazo no me menor a los tres meses.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

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

Radicle el GitHub p2p

Actualmente existen una gran cantidad de alternativas a GitHub, desde alternativas de código abierto, otras que son propias de algunos proyectos (es decir privadas), otras que son públicas, pero dejan mucho que desear, entre otras tantas.

Pero el escuchar una alternativa P2P a GitHub, si es algo de lo que no se sabe todos los días y es que navegando por la red me encontré con Radicle, el cual se presenta como una red de colaboración de código descentralizada, basada en la familiaridad de GitHub y GitLab como repositorios centralizados para la colaboración de código.

Sobre Radicle

Radicle aprovecha todas las características del sistema de control de versiones de Git y agrega descentralización, al mismo tiempo que integra una serie de características de identidad Web3 y como en su web se menciona » diferencia de las plataformas de alojamiento de código centralizado, no existe una entidad única que controle la red. Los repositorios se replican entre pares de manera descentralizada y los usuarios tienen control total de sus datos y flujo de trabajo.

En Radicle puedes iniciar un proyecto Radicle clonando algo almacenado en un repositorio de Git. Si ya estás usando Git pero quieres alejarte de uno de los repositorios centralizados, la experiencia de incorporación es bastante fluida. La interfaz de línea de comando será familiar para ti. Una diferencia clave es que no hay un único maestro inmutable en el que se fusionen los contribuyentes: cada par mantiene una versión ramificada del proyecto con los cambios que le interesa mantener.

El protocolo de red Radicle se centra en localizar, replicar y verificar repositorios en una red de alojamiento de código P2P. Su enfoque descentralizado garantiza el acceso a los repositorios, independientemente de su ubicación o número de réplicas. Utiliza un protocolo de chismes para el intercambio de metadatos entre nodos, facilitando el descubrimiento y la replicación del repositorio.

La arquitectura de Radicle es local primero , lo que garantiza el acceso continuo a los repositorios directamente desde su dispositivo, independientemente de la conectividad a Internet. Los repositorios tienen identificadores únicos y se autocertifican, lo que significa que todas las acciones, desde confirmar el código hasta agregar un comentario a un problema, se realizan localmente y están firmadas criptográficamente , lo que permite a los pares verificar la autenticidad y la procedencia de los datos una vez propagados a la red. Esto permite establecer confianza sin depender de una autoridad centralizada.

La mayoría de los proyectos de código abierto suelen estar alojados en GitHub u otras alternativas como GitLab, aunque ofrecen muchos beneficios, también tienen desventajas, como la pérdida de control y privacidad, como se vio en el caso de la eliminación del proyecto youtube-dl en GitHub. Radicle ofrece un enfoque descentralizado que garantiza el acceso a los repositorios sin importar su ubicación o número de réplicas.

Radicle funciona como un protocolo peer-to-peer donde cada usuario ejecuta un software idéntico, conocido como Radicle Stack. Este stack incluye una interfaz de línea de comandos y un servicio en red llamado Radicle Node, que intercambia datos a través de un protocolo de chismes para formar una red resistente.

Entre las características clave de Radicle que se destacan, podremos encontrar las siguientes:

• Capacidad para agregar múltiples pares remotos y administrarlos.
• Funcionalidad para seguir un proyecto de un par específico.
• No depende de servidores centrales, lo que evita la censura.
• Interconexión con otros pares en una red resistente y tolerante a las interrupciones.
• Capacidad para trabajar sin conexión y gestionar problemas locales y soluciones.
• Integrado con Git para una experiencia de desarrollo simple y cómoda.
• Posibilidad de recibir financiación mediante Ethereum y gestionar bases de código conjuntas.

Radicle está diseñado para ser una plataforma extensible que permite diversos casos de uso sin necesidad de modificaciones a nivel de protocolo. Aunque la versión inicial de Radicle se centra en la colaboración y publicación de código, se prevé una variedad de otras aplicaciones en el futuro y posibles hoy. Estos incluyen el intercambio de conocimientos, la coordinación de proyectos y la colaboración en conjuntos de datos, lo que amplía significativamente el alcance y la utilidad de la plataforma más allá de la gestión de código.

¿Como instalar Radicle en Linux?

Para los que estén interesados en utilizar Radicle, deben saber que existen diferentes métodos para instalarlo en Linux y uno de ellos es instalarlo en ejecutando lo siguiente:

curl -sSf https://radicle.xyz/install | sh

A ahora para quienes son usuarios de una distro Debian, Ubuntu o alguna derivada de estas, pueden realizar la instalacion tecleando:

sudo apt install curl
curl https://europe-west6-apt.pkg.dev/doc/repo-signing-key.gpg | sudo apt-key add -
echo deb https://europe-west6-apt.pkg.dev/projects/radicle-services radicle-cli main | sudo tee -a /etc/apt/sources.list.d/radicle-registry.list
sudo apt update
sudo apt install radicle-cli

Para conocer mas sobre el funcionamiento de Radicle, puedes consultar el siguiente enlace.

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

Nova un nuevo controlador del kernel Direct Rendering Manager (DRM) escrito en Rust

Desde que Nvidia libero sus módulos de kernel GPU como código abierto, parecía que tanto el controlador propietario de Nvidia como el controlador de código abierto Nouveau tendrían grandes mejoras con los aportes que podría realizar la comunidad e incluso que el algún momento Nouveau podría estar a la altura.

Después de varios meses y de que el desarrollo de Nouveau se llegara ralentizar, Red Hat ha tomado cartas en el asunto y hace poco dio a conocer la noticia de que se encuentra trabajando en el proyecto Nova, el cual presenta como un nuevo controlador abierto para GPU NVIDIA el cual está siendo desarrollado en Rust.

Este controlador incluye operaciones de inicialización y control de la GPU en el firmware, utilizando un microcontrolador GSP independiente. Nova está diseñado como un módulo para el kernel de Linux y utiliza el subsistema DRM (Direct Rendering Manager). Este proyecto se considera una continuación del desarrollo del controlador Nouveau para GPU con firmware GSP.

Danilo Krummrich (Red Hat) explica:

Con Nova tenemos la oportunidad de reducir significativamente la complejidad en comparación con Nouveau, por dos razones principales. En primer lugar, la arquitectura histórica de Nouveau, especialmente en torno a nvif/nvkm, es bastante complicada e inflexible y requiere una revisión importante para resolver algunos problemas. A continuación, también queremos aprovechar la oportunidad para contribuir a los esfuerzos de Rust en el kernel y beneficiarnos de la mayor seguridad de la memoria que ofrece el lenguaje de programación Rust.

Además de ello, se menciona que con el desarrollo de Nova, Red Hat pretende aprovechar la oportunidad para contribuir a los esfuerzos de Rust en el kernel, ya que como se mencionó el código del controlador está escrito en Rust y utiliza varias capas para desarrollar controladores de video en este lenguaje. Por ejemplo, el controlador utiliza abstracciones de la rama Rust-Device para crear controladores, componentes de la rama Rust-Pci para trabajar con el bus PCI, y enlaces para los subsistemas DRM y GEM de la rama Rust-DRM.

También se menciona el desarrollo del controlador drm-asahi Rust para GPU de chips Apple M1 y M2. El uso de Rust se espera que aumente la seguridad y confiabilidad del controlador al reducir la probabilidad de errores al trabajar con la memoria y permitir la combinación del trabajo en el controlador de video con el desarrollo de componentes comunes en Rust.

El objetivo de Nova es convertirse eventualmente en un controlador de código abierto para NVIDIA Linux, dirigido a las GPU Turing y modelos más recientes (especialmente en la serie RTX 2000) que admitan GSP. Este nuevo controlador está siendo desarrollado en Rust para lograr una mayor ligereza y flexibilidad, lo cual se presenta como una opción prometedora.

Una de las razones para crear un nuevo controlador es simplificar el proceso en comparación con Nouveau, gracias al uso de controladores listos para usar proporcionados por el firmware GSP. Esto evita la complejidad innecesaria en el código del controlador Nouveau, que necesita soportar GPU NVIDIA más antiguas y presenta problemas como bloqueos en el código VMM/MMU. Al desarrollar Nova desde cero y enfocarse solo en GPU basadas en GSP, se espera evitar estos problemas y complicaciones.

Por otra parte, Red Hat también menciona algunos de los puntos que debe abordar, ya que dice que con la elección de Rust, el primer problema a resolver es la falta de abstracciones de enlace de C para infraestructura integral del kernel:

«por ejemplo, abstracciones de dispositivo/controlador … necesitamos un usuario para las abstracciones en sentido ascendente, pero también necesitamos las abstracciones para crear un controlador: queremos desarrollar Nova en sentido ascendente y comenzar con solo un código auxiliar que solo haga uso de algunas abstracciones básicas de Rust.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace, asi como también consultar el desarrollo y consultar el código fuente de este en su repositorio.

from Linux Adictos https://ift.tt/dlBF9Jb
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

Intel dio a conocer hace poco, la noticia de que detecto una vulnerabilidad de microarquitectura (catalogada bajo CVE-2023-28746) en los procesadores Intel Atom (E-core), conocida como RFDS (Register File Data Sampling) y el peligro de esta vulnerabilidad radica en que permite determinar los datos utilizados por un proceso que se ejecutaba previamente en el mismo núcleo de la CPU.

RFDS es una vulnerabilidad que comparte similitudes con ataques de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), se diferencia en su método de exposición y los datos expuestos, limitándose a datos de registros obsoletos.

Sobre la vulnerabilidad

La identificación de «RFDS» fue realizada por ingenieros de Intel durante una auditoría interna, aunque no se ha proporcionado información detallada sobre el método de explotación de la misma, los ingenieros de Intel han señalado que el atacante no puede controlar intencionalmente la selección de procesos para la extracción de datos, lo que implica que la exposición de información disponible para su recuperación es aleatoria. Sin embargo, la explotación de RFDS por parte de un actor malicioso que pueda ejecutar código localmente en un sistema podría conducir a la inferencia de valores de datos secretos previamente utilizados en registros, potencialmente comprometiendo la seguridad y confidencialidad de la información.

RFDS se descubrió como parte del extenso trabajo de validación interna de Intel sobre seguridad de microarquitectura. De manera similar a los ataques de ejecución transitoria de muestreo de datos, como el muestreo de datos microarquitectónicos (MDS), RFDS puede permitir que un actor malicioso que puede ejecutar código localmente en un sistema infiera los valores de datos secretos que de otro modo estarían protegidos por mecanismos arquitectónicos. RFDS difiere de las vulnerabilidades de MDS tanto en el método de exposición como en los datos expuestos (RFDS expone únicamente datos de registros obsoletos). Ni MDS ni RFDS, por sí solos, brindan a los actores maliciosos la capacidad de elegir qué datos se infieren utilizando estos métodos.

Se menciona que estas fugas afectan a los registros vectoriales utilizados en cifrado, funciones de copia de memoria y procesamiento de cadenas, como en las funciones memcpy, strcmp y strlen. También es posible la fuga a través de registros para almacenar números de punto flotante y enteros, aunque se actualizan con más frecuencia durante la ejecución de tareas, lo que reduce la probabilidad de fugas a través de ellos. Es importante destacar que los datos residuales no permanecen directamente en los registros, sino que se pueden extraer de los archivos de registro mediante técnicas de ataque de canal lateral, como la extracción de datos en la memoria caché de la CPU.

RFDS afecta exclusivamente a los procesadores Atom basados en las microarquitecturas Alder Lake, Raptor Lake, Tremont, Goldmont y Gracemont. Estos procesadores no admiten el modo HyperThreading, lo que limita la fuga de datos a un subproceso de ejecución dentro del núcleo de la CPU actual. Los cambios para abordar esta vulnerabilidad están incluidos en la actualización del microcódigo microcode-20240312-staging.

Los métodos de protección contra esta vulnerabilidad son similares a los utilizados para bloquear ataques previamente identificados, como MDS, SRBDS, TAA, DRPW (Device Register Partial Write), y ataques SBDS (Shared Buffer Data Sampling).

Para protegerse contra las fugas en el kernel y los hipervisores, además de actualizar el microcódigo, es necesario utilizar métodos de protección de software que involucran el uso de la instrucción VERW para borrar el contenido de los buffers de microarquitectura al regresar del kernel al espacio de usuario o al transferir el control al sistema de invitados. Esta protección ya ha sido implementada en el hipervisor Xen y el kernel de Linux.

Para habilitar la protección en el kernel de Linux, se puede utilizar el indicador «reg_file_data_sampling=on» al cargar el kernel. La información sobre la vulnerabilidad y la presencia del microcódigo necesario para la protección se puede evaluar en el archivo «/sys/devices/system/cpu/vulnerabilities/reg_file_data_sampling«.

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

Linux es un núcleo mayormente libre semejante al núcleo de Unix.​ Es uno de los principales ejemplos de software libre y de código abierto.

La OpenELA (Open Enterprise Linux Association), una asociación formada el año pasado por CIQ (Rocky Linux), Oracle y SUSE (de la que ya hablamos aquí en el blog en su momento) se ha unido para garantizar la compatibilidad con RHEL (Red Hat Enterprise Linux). Dentro de este marco, han presentado el proyecto kernel-lts, el cual proporcionará soporte adicional para algunas ramas obsoletas de kernels LTS después de que dejen de recibir soporte oficial.

Con el lanzamiento de este proyecto, la versión 4.14, será la primera rama del kernel que recibirá este soporte adicional (esta versión del Kernel fue lanzada en noviembre de 2017 y ha recibido soporte durante 6 años). En enero, el equipo de desarrollo del kernel dejó de mantener esta rama y OpenELA ha asumido el mantenimiento y las actualizaciones para el kernel 4.14 se lanzarán al menos hasta diciembre de 2024. Tras la última versión del kernel de Linux 4.14.336, el equipo de OpenELA ha lanzado las actualizaciones extendidas 4.14.337-openela, 4.14.338-openela y 4.14.339-openela.

El mantenimiento proporcionado por OpenELA seguirá las mismas reglas y procesos que se aplican a los kernels LTS estables normales. No habrá restricciones adicionales, como la vinculación a equipos o productos específicos. Las actualizaciones se publicarán basadas en el trabajo de seguimiento de correcciones en las ramas actuales del kernel y su migración a las ramas LTS extendidas mantenidas por OpenELA.

El proyecto OpenELA kernel-lts es el primer foro para que los proveedores de distribución empresarial de Linux agrupen nuestros recursos y colaboren en esos kernels más antiguos después de que finalice el soporte upstream para esos kernels», dijo Greg Marsden, vicepresidente senior de Oracle Linux, Oracle. «Los proveedores de distribución empresarial de Linux que contribuyen al proyecto kernel-lts tienen kernels empresariales más recientes que recomendamos para la mayoría de las cargas de trabajo».

«Como proveedores de distribución empresarial, a menudo tenemos la tarea de mantener la viabilidad del software incluso después de que finalice el soporte de la comunidad», afirmó Gregory M. Kurtzer, director ejecutivo de CIQ. “Creemos que la colaboración abierta es la mejor manera de mantener la infraestructura empresarial fundamental. A través de OpenELA, los proveedores, los usuarios y la comunidad de código abierto en general pueden trabajar juntos para brindar la longevidad que las organizaciones profesionales de TI requieren para Linux empresarial”

Además de brindar soporte a las ramas del kernel LTS, OpenELA mantiene un repositorio con paquetes que pueden ser utilizados como base para crear distribuciones totalmente compatibles binariamente con Red Hat Enterprise Linux, manteniendo un comportamiento idéntico (a nivel de errores) a RHEL y adecuados para su uso como reemplazos de RHEL. Este repositorio es mantenido conjuntamente por los equipos de desarrollo de distribuciones como Rocky Linux, Oracle Linux y SUSE Liberty Linux, todas compatibles con RHEL. Incluye los paquetes necesarios para crear distribuciones compatibles con las ramas RHEL 8 y 9 (con planes para RHEL 7 en el futuro). Cabe destacar que este repositorio reemplazó al repositorio git.centos.org, que fue descontinuado por Red Hat.

Los desarrolladores del kernel de Linux continúan manteniendo varias ramas a largo plazo, cada una con su propio período de soporte:

1. Rama 6.6: Soportada hasta diciembre de 2026. Esta rama es utilizada en Ubuntu 24.04.
2. Rama 6.1: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 12 y la rama principal de OpenWRT.
3. Rama 5.15: Soportada hasta octubre de 2026. Esta rama es utilizada en Ubuntu 22.04, Oracle Unbreakable Enterprise Kernel 7 y OpenWRT 23.05.
4. Rama 5.10: Soportada hasta diciembre de 2026, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 11, Android 12 y OpenWRT 22.
5. Rama 5.4: Soportada hasta diciembre de 2025. Esta rama es utilizada en Ubuntu 20.04 LTS y Oracle Unbreakable Enterprise Kernel 6.
6. Rama 4.19: Soportada hasta diciembre de 2024, con soporte adicional dentro de SLTS. Esta rama es utilizada en Debian 10 y Android 10.

Además, la Fundación Linux proporciona ramas SLTS (Super Long Term Support) basadas en los Kernels 4.4, 4.19, 5.10 y 6.1. Estas ramas SLTS se mantienen por separado y reciben soporte durante períodos extendidos de 10 a 20 años. El proyecto Civil Infrastructure Platform (CIP) es responsable de mantener estas ramas SLTS, con la participación de empresas como Toshiba, Siemens, Renesas, Bosch, Hitachi, MOXA, mantenedores de las ramas LTS del núcleo principal, desarrolladores de Debian y el proyecto KernelCI. Estas ramas SLTS están diseñadas para su aplicación en sistemas técnicos de infraestructura civil y en sistemas industriales críticos.

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/J8TjoF0
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 por parte de los desarrolladores del proyecto GrapheneOS, sobre una vulnerabilidad que detectaron en Android 14 en la pila Bluetooth LE, el error se debe a una corrupción de memoria introducido en Android 14 QPR2.

Para quienes desconocen de GrapheneOS, deben saber que este es un proyecto que desarrollar una versión segura del código base de AOSP, y ellos fueron quienes detectaron la vulnerabilidad en la pila Bluetooth de Android 14 la cual mencionan que puede ser explotada y permite conducir a la ejecución remota de código.

Sobre la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que esta se origina en el acceso a un área de memoria liberada previamente, lo que se conoce como «uso después de liberación» (use-after-free). El problema se encuentra en el código encargado de procesar audio transmitido a través de Bluetooth LE.

Nuestra compatibilidad con el etiquetado de memoria de hardware para Pixel 8 y Pixel 8 Pro ha descubierto un error de corrupción de memoria introducido en Android 14 QPR2 para Bluetooth LE. Actualmente lo estamos investigando para determinar cómo solucionar o desactivar temporalmente la función recién introducida como solución alternativa.

La identificación de esta vulnerabilidad se debe en parte a la implementación de protecciones adicionales mediante la función hardened_malloc, que utiliza la extensión ARMv8.5 MTE. Esta extensión permite asignar etiquetas a cada operación de asignación de memoria y realizar verificaciones para garantizar el uso correcto de los punteros, evitando así la explotación de vulnerabilidades relacionadas con el acceso a memoria liberada, desbordamientos de búfer, llamadas a funciones antes de su inicialización y uso fuera del contexto actual.

Este error comenzó a surgir después de la actualización a Android 14 QPR2 (versión trimestral de plataforma), lanzada a principios de marzo. En la versión principal del código de Android 14, la funcionalidad MTE está disponible como opción pero aún no se encuentra habilitada de forma predeterminada.

Sin embargo, en GrapheneOS, se ha activado la protección MTE para proporcionar una capa adicional de seguridad, lo que permitió identificar el error después de la actualización a Android 14 QPR2. Este error causó bloqueos al utilizar auriculares Bluetooth Samsung Galaxy Buds2 Pro con firmware que habilitaba la protección basada en MTE. El análisis posterior del incidente reveló que el problema estaba relacionado con el acceso a memoria liberada en el controlador Bluetooth LE, y no fue causado por la integración de la funcionalidad MTE en sí misma.

Por la parte de las posibles soluciones a la vulnerabilidad, los desarrolladores de GrapheneOS mencionan que el deshabilitar el etiquetado de memoria para este proceso no es una solución alternativa aceptable ni siquiera a corto plazo porque es una superficie de ataque importante, independientemente de que este error en particular resulte explotable o no. Esto solo ocurre con ciertos dispositivos Bluetooth LE, no con todos los dispositivos Bluetooth.

La vulnerabilidad mencionada se ha solucionado en la versión 2024030900 de GrapheneOS. Es importante destacar que esta vulnerabilidad afecta a versiones de teléfonos inteligentes que no cuentan con protección de hardware adicional basada en la extensión MTE. Actualmente, la extensión MTE está habilitada únicamente para dispositivos Pixel 8 y Pixel 8 Pro.

Desarrollamos un parche para el error de uso después de la liberación de QPR2 de Android 14 que descubrimos con Bluetooth LE. Nuestra prioridad es lanzar pronto una versión de GrapheneOS con nuestra solución y lo informaremos como un error de seguridad de Android. Esto también debería resolver las regresiones de audio BLE.

La vulnerabilidad se ha observado en los smartphones Google Pixel 8 con firmware basado en Android 14 QPR2. Para los dispositivos de la serie Pixel 8, es posible habilitar el modo MTE en la configuración del desarrollador. Esto se puede hacer accediendo a «Configuración/Sistema/Opciones de desarrollador/Extensiones de etiquetado de memoria». Es importante tener en cuenta que habilitar MTE conlleva un aumento en el consumo de memoria de aproximadamente un 3 %, pero no afecta el rendimiento del dispositivo.

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

Hace poco más de un mes, el Centro de Aplicaciones de Ubuntu cambió de imagen. Lo hizo en Ubuntu 24.04, actualmente en desarrollo, pero también en la última versión estable, 23.10 en el momento de escribir este artículo. Se abrieron hilos preguntando por el cambio, más tarde nos enteramos de que era un bug y poco después volvió a la normalidad. El viaje ha sido de ida, vuelta y vuelta a ir, puesto que en las últimas horas tenemos nuevo icono, pero este cambio parece que se mantendrá. Y el destino, aunque diferente al origen, es un tercer punto.

Del mismo modo que en la vez anterior, si nos desplazamos a la página de GitHub del Centro de Aplicaciones, vemos que hay un commit en el que se describe la eliminación del logotipo anterior y la adición del nuevo. Si nos fijamos en las imágenes, tanto la anterior como la actual tienen en la parte inferior una parte más clara, algo que yo no había visto hasta hoy. La bolsa ha pasado de ser algo más parecido a una maleta a una que se parece más a una de compras.

El Centro de Aplicaciones cambia de look

Lo que es el diseño general queda consistente en el tema por defecto de Ubuntu, a diferencia del del bug que era una imagen plana. Y se espera que sea así a partir de Ubuntu 24.04.

Para ver el nuevo icono, hay que escribir sudo snap refresh en Ubuntu 24.04; en versiones anteriores del sistema operativo de Canonical se sigue con el icono y versiones de la tienda anteriores. Lo que no cambia ni cambiará es que sigue siendo una tienda en formato snap, que prioriza este tipo de paquetes y no soporta paquetes flatpak.

Ubuntu 24.04 Noble Numbat llegará el 25 de abril con las principales novedades de GNOME 46 lanzado la semana pasada y el kernel Linux 6.8.

code {background-color: rgba(255, 255, 0, 0.18); color: #d63384; padding: 1px 3px; font-family: monospace; border-radius: 2px;}

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

firefox Manifest V3

Hace poco los desarrolladores de Mozilla que están a cargo de Firefox, dieron a conocer sus planes relacionados con el soporte de las versiones 2 y 3 del manifiesto de Chrome en Firefox. Y es que, aunque Google tiene la intención de dejar de admitir complementos que utilicen la segunda versión del manifiesto en las versiones de prueba de Chrome 127  Mozilla ha decidido no dejar de admitir la segunda versión del manifiesto en el futuro previsible.

Además de ello Mozilla asegura que mantendrá la capacidad de lanzar complementos que utilicen funciones no disponibles en la tercera versión del manifiesto. La decisión de no hacer que Firefox sea totalmente compatible con la versión 3 del manifiesto de Chrome sigue vigente. Firefox conservará la API webRequest completa, la cual cambiará al modo de solo lectura en Chrome.

Además, Firefox utilizará el mecanismo de páginas de eventos para conservar el soporte para ejecutar scripts en segundo plano basados en el DOM. Mientras que la tercera versión del manifiesto requiere el uso de Service Workers, los scripts en segundo plano basados en Service Workers aún no son compatibles con Firefox. Sin embargo, los desarrolladores tendrán la oportunidad de definir tanto un controlador basado en páginas de eventos como scripts basados en Service Workers en el complemento, lo que les permitirá crear complementos que cumplan con la tercera versión del manifiesto y funcionen en Chrome y Firefox.

El manifiesto de Chrome define las capacidades y recursos disponibles para las extensiones escritas utilizando la API WebExtensions. Desde la versión 57, Firefox pasó por completo a utilizar la API WebExtensions para desarrollar complementos, abandonando la tecnología XUL.

Esta transición permitió unificar el desarrollo de complementos con otras plataformas como Chrome, Opera, Safari y Edge, simplificó la transferencia de complementos entre diferentes navegadores web y habilitó completamente el modo multiproceso de operación. Firefox proporciona compatibilidad casi total con la segunda versión del manifiesto de Chrome para unificar el desarrollo de complementos con otros navegadores.

Como parte de una iniciativa para facilitar la creación de complementos seguros y de alto rendimiento, y dificultar la creación de complementos lentos e inseguros, Google ha desarrollado la versión tres del manifiesto. Sin embargo, ha habido descontento principalmente debido a la traducción al modo de solo lectura de la API webRequest en la tercera versión del manifiesto.

La principal preocupación con la tercera versión del manifiesto radica en la traducción de la API webRequest al modo de solo lectura, lo que ha generado cierto descontento entre los desarrolladores. Esta API permitía conectar controladores propios que tenían acceso completo a las solicitudes de red y podían modificar el tráfico de manera dinámica. En lugar de la API webRequest, la tercera versión del manifiesto agregó la API declarativaNetRequest, que tiene capacidades más limitadas y proporciona acceso al motor de filtrado integrado sin permitir el uso de algoritmos de filtrado propios.

A pesar de estas diferencias y desafíos, Firefox ha implementado características importantes al adoptar la tercera versión del manifiesto de Chrome:

• Una nueva API de filtrado de contenido declarativo en la cual se ha mantenido la compatibilidad con el antiguo modo de bloqueo de la API webRequest.
• Implementación del mecanismo de Páginas de eventos: Este mecanismo elimina las limitaciones asociadas con el uso de Service Workers y permite que las adiciones de páginas de fondo cumplan con los requisitos de la tercera versión del manifiesto.
• Firefox ha introducido un nuevo modelo de permisos que requiere la aprobación del usuario para cada sitio en el que el complemento desea funcionar.
• Se ha agregado un botón «Extensiones unificadas» para controlar directamente el acceso de cada complemento a los sitios.
• Cambio en el procesamiento de solicitudes de origen cruzado: Se aplican las mismas restricciones de permisos a los scripts de procesamiento de contenido que a la página principal en la que están integrados.
• Firefox ha implementado restricciones para evitar la ejecución de código descargado de fuentes externas, aumentando así la seguridad de los complementos.

Finalmene 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/LBU1Cf2
via IFTTT

Vulnerabilidad GhostRace

Se dio a conocer hace poco, información sobre un nuevo ataque de ejecución especulativa, bautizado como GhostRace (catalogado bajo CVE-2024-2193), este es un nuevo método desarrollado por investigadores de la Vrije Universiteit Amsterdam e IBM para explotar el mecanismo de ejecución especulativa presente en procesadores modernos de Intel, AMD, ARM e IBM.

Los investigadores mencionan que, GhostRace se enfoca en manipular condiciones de carrera especulativas para acceder a áreas de memoria previamente liberadas, lo que puede llevar a la extracción de datos sensibles del kernel de Linux, especialmente en entornos de virtualización donde un atacante en un sistema invitado puede comprometer la seguridad del sistema anfitrión o de otros sistemas invitados.

El funcionamiento del ataque se basa en la ejecución especulativa de instrucciones condicionales con primitivas de sincronización de subprocesos, como mutex y spinlock. Si el procesador predice incorrectamente ramas en el código que manejan estas operaciones, se pueden realizar accesos especulativos a la memoria que ya ha sido liberada. Aunque el procesador descarta estos accesos después de detectar la predicción errónea, los rastros de ejecución permanecen en la memoria caché y pueden ser recuperados mediante técnicas de análisis de canal lateral.

GhostRace requiere la presencia de ciertas secuencias de instrucciones en el kernel, conocidas como gadgets, que son utilizadas para la ejecución especulativa dependiendo de condiciones externas controladas por el atacante. Estos gadgets se forman a partir de secciones de código donde se verifica el estado en un bucle sin fin y se sale del bucle después de eliminar el bloqueo de acceso al recurso. Esto permite activar falsamente una transición y ejecutar instrucciones protegidas por un bloqueo, a pesar de que el recurso permanece bloqueado.

Durante el análisis de la vulnerabilidad, que se realizó en el código del kernel de Linux 5.15.83, se reveló la presencia de 1283 dispositivos que podrían conducir a un acceso especulativo a la memoria ya liberada. Este tipo de ataque representa un riesgo potencial para sistemas de virtualización, cualquier kernel del sistema operativo y programas que utilicen primitivas de sincronización de subprocesos verificadas mediante declaraciones condicionales y se ejecuten en plataformas que permitan la ejecución especulativa de operaciones de ramificación, como x86, ARM, RISC-V, entre otros.

Para probar la vulnerabilidad, los investigadores desarrollaron un prototipo de exploit que demuestra la efectividad del ataque al permitir la extracción de datos de la memoria del kernel de Linux con un rendimiento de 12 KB por segundo y un nivel de confiabilidad similar a los ataques de la clase Spectre. Es importante destacar que este tipo de ataques enfocados en la ejecución especulativa representan un desafío significativo para la seguridad de los sistemas informáticos modernos y requieren medidas de mitigación adecuadas por parte de los fabricantes de hardware y software.

Los desarrolladores del kernel de Linux y las empresas de fabricación de CPU fueron informados sobre este problema a finales de 2023. AMD ya ha publicado un informe sobre la vulnerabilidad y recomienda el uso de técnicas estándar para protegerse contra ataques similares a Spectre v1. Por otro lado, Intel y ARM aún no han respondido a esta notificación.

Aunque los desarrolladores del kernel de Linux no tienen planes inmediatos de implementar la serialización de primitivas de sincronización debido a la pérdida de rendimiento, ya han incorporado restricciones para protegerse contra la técnica de explotación IPI Storming (CVE-2024-26602). Esta técnica de ataque implica interrumpir un proceso en el momento adecuado para proporcionar una ventana de tiempo para el acceso especulativo a la memoria liberada.

Para mitigar este tipo de ataque, se propone utilizar la serialización de primitivas de sincronización mediante la inclusión de una instrucción LFENCE después de la instrucción cmpxchq que verifica el estado de bloqueo. Sin embargo, esta medida de protección conlleva una penalización de rendimiento de aproximadamente el 5 % en el punto de referencia LMBench, debido a que la instrucción LFENCE deshabilita la ejecución preventiva de instrucciones posteriores antes de confirmar todas las operaciones anteriores.

En el caso del hipervisor Xen, los desarrolladores han preparado cambios para implementar el mecanismo de bloqueo protegido LOCK_HARDEN, similar al método BRANCH_HARDEN utilizado anteriormente. Sin embargo, debido a posibles impactos negativos en el rendimiento y la falta de evidencia de ataques en Xen, el modo LOCK_HARDEN está deshabilitado de forma predeterminada.

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