systemd es un conjunto de demonios o daemons de administración de sistema, bibliotecas y herramientas diseñados como una plataforma de administración y configuración central para interactuar con el núcleo del Sistema operativo GNU/Linux

Después de cinco meses de desarrollo, se dio a conocer el lanzamiento de la nueva versión de systemd 254, en la cual una de sus principales novedades es la compatibilidad con un modo de reinicio suave, asi como tambien una nueva utilidad para verificar el nivel de batería, mejoras, correcciones y más.

En esta nueva versión que se presenta de systemd 254, como ya mencionamos una de sus principales novedades es la compatibilidad con un modo de reinicio suave que hace que solo los componentes del espacio del usuario se reinicien sin tocar el kernel de Linux. En el nuevo modo, al reiniciar, no se aplican las etapas de inicialización del hardware, llamada del cargador de arranque, inicio y carga del kernel, inicialización del controlador, carga del firmware y procesamiento initrd, lo que permite acelerar significativamente el reinicio y reducir el tiempo de inactividad durante la actualización de entornos utilizando imágenes de sistema listas para usar.

El nuevo modo permite cerrar todos los procesos en el espacio del usuario, luego reemplazar la imagen del FS root con una nueva versión e iniciar el proceso de inicialización del sistema sin reiniciar el kernel.

Otros de los cambios que se destaca de la nueva versión es la utilidad «systemd-battery-check» para verificar el nivel de la batería. La utilidad se puede iniciar en una etapa temprana del inicio para evitar que el sistema se inicie con un nivel de batería muy bajo.

Para las unidades de servicio, se proponen los ajustes MemoryPressureWatch y MemoryPressureThresholdSec, que permiten controlar la lógica de uso del subsistema PSI (Pressure Stall Information) en relación con los servicios individuales. PSI proporciona información sobre el tiempo de espera para obtener varios recursos para evaluar con precisión el nivel de carga del sistema, lo que permite identificar el comienzo de retrasos debido a la falta de recursos y terminar selectivamente los recursos intensivos.

Ademas de ello, tambien se destaca que se agregó la configuración RootEphemeral, que permite usar en los servicios donde se establecen los parámetros RootImage y RootDirectory, copias temporales de una imagen de disco o árbol de directorio, que se crean a través de btrfs y reflink-y btrfs/xfs snapshots cuando se inicia el servicio, y se eliminan después de detener el servicio.

Tambien podremos encontrar que se añadió el comando «fdstore» a la utilidad systemd-analyze para mostrar el contenido del almacén de descriptores de archivos asociado con una unidad (usado para reiniciar servicios sin estado; los descriptores de archivos se almacenan en fdstore antes de salir y restaurarse al iniciar).

Por otra parte, para systemd-resolved, el parámetro StateRetentionSec se agregó a resolve.conf, lo que permite que los registros DNS se almacenen en caché durante más tiempo del especificado a través de TTL y se usen si el servidor DNS ascendente deja de responder. El comando «show-cache» se ha agregado a la utilidad resolvectl para ver el contenido de la caché de DNS.

De los demás cambios que se destacan de esta nueva versión:

• Se agregó la opción «–when» a los comandos de reinicio, kexec, apagado y detención en la utilidad systemctl para permitirle seleccionar cuándo reiniciar o detener.
• Añadidas las opciones «–fd» y «–fdname» a la utilidad systemd-notify para enviar descriptores de archivos arbitrarios al administrador de servicios.
• Se agregó la opción «–exec» para ejecutar el comando especificado después de enviar el mensaje.
• Se agregó el comando «systemctl list-paths» para mostrar todas las unidades de ruta activas, similar a los comandos «systemctl list-timers» y «systemctl list-sockets».
• Se agregó la capacidad de las unidades para establecer la configuración de la memoria de inicio (Startup*, por ejemplo, StartupMemoryMax), que se usa de manera similar a la configuración de inicio de E/S y CPU (StartupCPUWeight, etc.).
• El proceso PID carga automáticamente los módulos virtio_console y virtio-vsock para máquinas virtuales.
• Para las unidades de servicio, se agregó la configuración DelegateSubgroup, que le permite colocar servicios en subgrupos existentes en lugar de crear un cgroup superior separado para el servicio.
• Se agregó el comando «whoami» a la utilidad systemctl para mostrar el nombre de la unidad con la que está asociado el PID especificado.
• Se agregó la opción ‘–list-cvm’ a systemd-detect-virt para enumerar las máquinas virtuales confidenciales.
• El script de instalación del kernel se ha reescrito en C.

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/iXIvCOV
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 pocos días un investigador del equipo de seguridad de Google, dio a conocer la noticia de que detecto una vulnerabilidad (ya catalogada bajo CVE-2023-20593) en los procesadores AMD basados ​​en la microarquitectura Zen2 que se puede utilizar para detectar registros mientras otros procesos se ejecutan en el mismo núcleo de la CPU.

Esta vulnerabilidad se considera importante, ya que el ataque se puede realizar desde máquinas virtuales y entornos aislados. En esencia, el problema se parece a las vulnerabilidades clásicas de uso después de liberar causadas por el acceso a la memoria después de que se haya liberado.

El problema ocurre con AMD Ryzen 3000, Ryzen PRO 3000, Ryzen Threadripper 3000, Ryzen 4000 con Radeon Graphics, Ryzen PRO 4000, Ryzen 5000 con Radeon Graphics, Ryzen 7020 con Radeon Graphics y la serie de procesadores EPYC 7002.

Sobre la vulnerabilidad, se menciona se debe a que en los procesadores, para almacenar el contenido de los registros, se utiliza un archivo de registro (RF, Register File), que es un arreglo que se comparte en todas las tareas en el mismo núcleo de la CPU. La tabla de asignación de registros (RAT) es responsable de adjuntar registros con nombres específicos a los recursos del archivo de registro. En este caso, el valor cero se almacena en el registro no almacenando un valor vacío en el archivo de registro, sino configurando el indicador de bit z en la tabla RAT.

La vulnerabilidad se debe al hecho de que si el bit z se establece durante la ejecución especulativa de instrucciones, no es suficiente simplemente restablecerlo en caso de una predicción de bifurcación incorrecta, ya que el espacio en el archivo de registro se puede reasignar a partir de la ejecución especulativa.

El efecto revelado ocurre cuando simultáneamente se cambia el nombre de un registro, se usa una instrucción para la cual se aplica la optimización de combinación y se ejecuta especulativamente una instrucción vectorial VZEROUPPER que establece el bit z y libera recursos del archivo de registro. Si la predicción de bifurcación falla y la operación especulativa VZEROUPPER se deshace, el contenido de los registros vectoriales puede corromperse, ya que el bit z se deshace, pero el recurso liberado permanece sin descartar.

A través de la manipulación de la instrucción VZEROUPPER, es posible lograr una fuga controlada de datos procesados ​​en los registros vectoriales YMM utilizados en los modos AVX (Advanced Vector Extensions) y SSE (Streaming SIMD Extensions). Estos registros se usan activamente en las funciones de copia de memoria y procesamiento de cadenas, por ejemplo, en la biblioteca Glibc se usan en las funciones memcpy, strcmp y strlen.

Para demostrar la vulnerabilidad, cuyo nombre en código es Zenbleed, se ha preparado un prototipo de exploit que permite a un usuario sin privilegios determinar los datos procesados ​​en las instrucciones AES-NI o ​​REP-MOVS (normalmente utilizadas en la función memcpy), que pueden utilizarse para reconstruir claves de cifrado y contraseñas de usuario, procesadas en otros procesos, incluidos los privilegiados. El rendimiento de fuga de datos del exploit es de aproximadamente 30 KB por segundo.

La vulnerabilidad se corrigió en el nivel de actualización del microcódigo. Para Linux se ha preparado un parche para descargar el microcódigo corregido. Aunque si no es posible actualizar el microcódigo, existe una solución para bloquear la vulnerabilidad, lo que conduce a una disminución del rendimiento.

Para ello, se debe configurar el bit de control DE_CFG[9] en la CPU y para ello, en una terminal se debe teclear el siguiente comando:

Cabe mencionar que deshabilitar el modo SMT no bloquea la vulnerabilidad y la solución para bloquear la vulnerabilidad fue implementada dentro de las actualizaciones del kernel 6.4.6, 6.1.41, 5.15.122, 5.10.187, 5.4.250 y 4.19.289.

Para los interesados en dar seguimiento a la información de vulnerabilidad en las diferentes distribuciones, pueden hacerlo en las siguientes páginas: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch, OpenBSD, FreeBSD, NetBSD.

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

Linus Benedict Torvalds es un ingeniero de software, conocido por iniciar y mantener el desarrollo del kernel Linux

En las listas de correo de los desarrolladores del Kernel de Linux, Linus Torvalds, expresó su “frustración” con la implementación del módulo fTPM de AMD.

Y es que para el creador de Linux, el modulo fTPM de AMD es algo “tonto”, ya que parece sugerir que lo mejor que se puede hacer con esta solución TPM sería deshabilitarla, al menos en lo que respecta a su uso para la generación de hardware de números aleatorios.

Linus Torvalds menciona que el problema de fTPM está perjudicando el rendimiento de Linux, además de que señala que la instrucción RDRAND podría usarse en su lugar para la misma tarea.

fTPM es una solución específica que se ejecuta en un entorno seguro en un procesador. El propósito de este TPM es resolver errores encontrados solo en el software del procesador. Muchas empresas, como AMD e Intel, utilizan fTPM para la seguridad de su hardware. Básicamente, los TPM, ya sea basados ​​en firmware o en hardware, se utilizan para crear y almacenar de forma segura claves criptográficas, certificados y contraseñas. Los módulos también generan, entre otras cosas, números aleatorios para uso del software. Sin embargo, en el caso del fTPM de AMD, existen algunos fallos de funcionamiento.

Se menciona que cuando se usa el fTPM de AMD, accede a su almacenamiento flash a través de una interfaz serie y, al hacerlo, retrasa la actividad del resto del sistema. Si el módulo se usaba con frecuencia, por ejemplo, mediante software que generaba flujos de números aleatorios, el resultado final para los usuarios de los sistemas afectados era una caída en el rendimiento.

Según AMD, algunas configuraciones del sistema AMD Ryzen pueden realizar de forma intermitente transacciones de memoria extendida relacionadas con fTPM en la memoria flash SPI (SPIROM) ubicada en la placa base. Lo que puede causar pausas temporales en la interactividad o capacidad de respuesta del sistema hasta que se complete la transacción.

El problema apareció en las PC con Windows y se resolvió con una actualización del BIOS que arregló el fTPM para mejorar su funcionamiento, aunque también el problema afectó a Linux, y aunque parecía que un parche a nivel del kernel había solucionado el error, la ralentización reapareció, provocando la ira de Linus Torvalds.

«Simplemente deshabilitemos el estúpido fTPM hwrnd», dijo Torvalds el jueves en la lista de correo de desarrollo del núcleo de código abierto.

Como tal el enojo de Linus Torvalds no fue la “solución” implementada, sino que el problema aún afecta a quienes no han instalado la actualización de BIOS necesaria, además de que la solución no tuvo en cuenta todas las iteraciones del firmware con errores, o que el firmware no se arregló por completo, por lo que para algunos usuarios el problema persiste.

De ahí la sugerencia de desactivar el generador de números fTPM, independientemente de la versión.

«¿Por qué alguien usaría esta basura cuando cualquier máquina que supuestamente la arregló, lo que aparentemente no funcionó después de todo, también tendría la instrucción CPU rdrand que no tiene el problema? No veo el daño de simplemente decir que esto de fTPM no funciona. Incluso si termina funcionando en el futuro, hay alternativas que no son peores”, escribió. Él reconoce que RdRand (que devuelve números aleatorios de un generador de números aleatorios incorporado) puede ser lento, pero en comparación con los tartamudeos causados ​​por fTPM, Torvalds cree que puede ser la mejor solución.

“De hecho, rdrand, y rdseed en particular, pueden ser bastante lentos. Pero creo que estamos hablando de cientos de ciclos de CPU, tal vez unos pocos miles. Nada como los tartamudeos que vimos con fTPM”, escribió. La causa real del error aún no está clara, aunque Torvalds ha ofrecido algunas teorías sobre lo que podría estar pasando. En otro extenso comentario sobre el estado del fTPM de AMD, Torvalds pareció arrojar sombra sobre los codificadores BIOS de la placa base antes de hacer una observación clave sobre RDRAND basado en CPU versus HWRND basado en fTPM. 

Finalmente cabe mencionar que AMD sugirió anteriormente usar un TPM físico como alternativa al firmware TPM que usan muchas placas base lo que no toma en cuenta es que también se necesita una placa base con el encabezado adecuado para aceptar dicho módulo, lo cual no está garantizado.

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