The Document Foundation ha lanzado la segunda actualización de mantenimiento de la historia de la suite de ofimática con nueva numeración. En febrero de 2024 se dejó atrás el número de versión, digamos, normal y ahora usa año y mes. Lo que hay disponible desde hace unos instantes es LibreOffice 24.2.2, y como lanzamiento de punto está aquí para corregir los errores que han ido encontrando desde el lanzamiento de la versión anterior.

Al mismo tiempo, también hay disponible una actualización para el canal still, es decir, la versión recomendada para equipos de producción que no incluye las últimas novedades pero sí más parches que le hacen ser más fiable. En LibreOffice 24.2.2 se han corregido un total de 79 bugs, 63 en la RC1 y 13 más en la RC2. Por su parte, en 7.6.6 se han corregido 33 errores.

LibreOffice 24.2.2 sigue sin recomendarse para equipos de producción

LibreOffice 24.2.2 sigue sin recomendarse para equipos de producción, y seguirá así al menos hasta 24.2.5, siempre y cuando se siga con las viejas costumbres. Esta debe ser la elección para aquellos que prioricen nuevas funciones a estabilidad, mientras que 7.6.6 debe ser la de los que prefieren ir sobre seguro.

Ambos son lanzamientos menores que corrigen fallos y regresiones, y se pueden descargar desde la página de descargas del proyecto. TDF recuerda que existe la versión Enterprise para su uso empresarial, lo que es lo mismo que la normal o Community, pero con soporte directo de la compañía y es posible añadir funciones a la carta.

Los usuarios de Linux podemos instalarlo desde los paques DEB y RPM que ofrecen en su página web y también desde repositorios oficiales, la mayoría por actualizar. En las próximas horas también se actualizarán sus paquetes flatpak y snap. La próxima versión del canal fresh será LibreOffice 24.2.3 y llegará en un plazo aproximado de seis semanas.

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

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine

Se dio a conocer el lanzamiento de la nueva versión de la capa DXVK 2.3.1, la cual llega con las correcciones para una gran cantidad de errores en diferentes títulos, así como también con las mejoras de soporte para extensiones Vulkan, actualización de dependencias y más.

La nueva versión de DXVK 2.3.1 ahora requiere controladores que admitan la API Vulkan 1.3, como Mesa RADV 22.0, NVIDIA 510.47.03, Intel ANV 22.0 y AMDVLK. DXVK es utilizado para ejecutar aplicaciones y juegos 3D en Linux con Wine, ofreciendo un rendimiento superior a las implementaciones nativas Direct3D 9/10/11 de Wine sobre OpenGL.

¿Que hay de nuevo en DXVK 2.3.1?

En esta nueva versión de DXVK 2.3.1, se ha implementado para sistemas y si el controlador lo admite, la extensión Vulkan VK_NV_raw_access_chains aumenta la eficiencia de generar código de sombreado en las GPU NVIDIA, acercando el rendimiento de algunos juegos D3D11 al rendimiento en Windows con controladores de NVIDIA 550.40.55 o superiores y versiones de Proton Experimental.

Ademas de ello, se rediseñó del método de copiar buffers del sistema a la GPU para juegos D3D9, resultando en un rendimiento mejorado en juegos como Shank 2, Flammable Freddy y Blood Rayne.

Por la parte de las correcciones de errores en titulos y otras mejoras menores en DXVK 2.3.1:

• Se corrigió la generación de SPIR-V no válido para los sombreadores internos D3D11 de Renderdoc.
• Se corrigió el comportamiento indefinido con cargas de búfer constantes fuera de límites con índices dinámicos.
• Se corrigió que HDR no estuviera habilitado para DXGI_FORMAT_R16G16B16A16_FLOAT cadenas de intercambio.
• Se modificó la opción dxgi.syncInterval para que también se aplique a los juegos D3D12.
• Se revirtió el uso de VK_FORMAT_A8_UNORM debido a problemas de renderizado en algunos juegos.
• Los juegos D3D9 ahora establecerán el VkApplicationInfo::applicationVersion campo en 1.
• Se modificó la forma en que se copian los buffers de memoria dinámica del sistema a la GPU en los juegos D3D9, mejorando el rendimiento en juegos como Shank 2, Flammable Freddy y Blood Rayne.
• Se habilitó solo la cobertura alfa al renderizar en un destino de renderizado multimuestreado en D3D9, corrigiendo problemas de iluminación y tramado incorrecto en algunos juegos.
• En Assassin’s Creed 2 se corrigió el bloqueo en la pestaña alternativa. 
• Total War: Medieval 2 se reparo la pantalla de carga negra en modo ventana
• En Battlefield 2 y Battlefield 2142: Se corrigió la desaparición de la interfaz de usuario de selección de equipo y generación en la pestaña alternativa. 
• Se corrigieron bloqueos y problemas específicos en juegos como Ace Combat Assault Horizon, Battlestations Midway, Nombre en clave Panzers Fase uno/dos, Dead Space (2008), Granblue Fantasy Relink, Gujian 2, Kenshi, MySims, Operation Flashpoint: Red River, SkyDrift, Sonic CD, Supreme Ruler Ultimate, Cuentos de Borderlands, The Settlers, UK Train Simulator 1 y War Thunder.

Finalmente si estás interesado en conocer más al respecto sobre este nuevo lanzamiento, puedes consular los detalles en el siguiente enlace.

¿Cómo añadir el soporte de DXVK a Linux?

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, actuando como una alternativa de mayor rendimiento a la implementación de Direct3D 11 integrada en Wine que se ejecuta sobre OpenGL.

DXVK requiere de la última versión estable de Wine para ejecutarse. Por lo que, si no cuentas con este instalado. Ahora solo tendremos que descargar el último paquete estable de DXVK, este lo encontramos en el siguiente enlace.

wget https://github.com/doitsujin/dxvk/releases/download/v2.3/dxvk-2.3.tar.gz

Después de haber realizado la descarga ahora vamos a descomprimir el paquete recién obtenido, esto lo pueden hacer con desde su entorno de escritorio o desde la misma terminal ejecutando en el siguiente comando:

tar -xzvf dxvk-2.3.1.tar.gz

Después accedemos a la carpeta con el siguiente comando:

cd dxvk-2.3.1

Dentro de la carpeta podremos encontrar los archivos necesarios para nuestros prefijos de Wine, tanto de 32 bits como de 64 bits estas las vamos a colocar de acuerdo a las siguientes rutas.
En donde “usuario” lo remplazas por el nombre de usuario que utilizas en tu distribución de Linux.

Para 64 bits las colocamos en:

~/.wine/drive_c/windows/system32/

O

/home/”usuario”/.wine/drive_c/windows/system32/

Y para 32 bits en:

~/.wine/drive_c/windows/syswow64

O

/home/”usuario”/.wine/drive_c/windows/system32/

O en el caso de que tengas identíficado el prefijo donde vas a ocupar los archivos:

export WINEPREFIX=/path/to/wineprefix
cp x64/*.dll $WINEPREFIX/drive_c/windows/system32
cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64
winecfg

De igual forma te invito a que consultes la documentación de uso y de compilación, si es de tu interés, en el siguiente enlace.

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

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