Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image) que combina la imagen del kernel de Linux, el controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en memoria, utilizado para inicialización inicial en la etapa antes de montar el FS. En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en el UKI, lo que permite la creación de entornos de sistema totalmente verificados que se cargan en la RAM.
Comentarios
Desde las Costas de la Ignorancia, yo estoy más que satisfecho...
#4 Increible comparatica. Y si todo en linux es mejor que windows, ¿cómo es que no lo usa todo el mundo?
No me digas más, tu también crees que este es el año de linux en el escritorio...
#20 https://www.google.com/search?client=opera&q=comparatica&sourceid=opera&ie=UTF-8&oe=UTF-8
Todo aspirante a troll, merece algún que otro hueso
El initramfs puede meterse en el núcleo desde hace ya algún tiempo. Y ya existen formas de arranque fiable:
https://wiki.gentoo.org/wiki/Trusted_Boot
#3
Ahora en UEFI debes poner un cargador EFI en la particion FAT32 correspondiente.
No me lo recuerdes, que un sistema de arranque necesite ese sistema de archivos me parece subrealista.
Por lo que veo lo que buscan es una especie de meter el gestor de arranque también, a.k.a grub con su apoyo UEFI en el núcleo.
Ahora bien, espero que cambien FAT por otra cosa, porque si núcleo, EFI e initramfs permanecen en vfat me da algo, como si no se corrompiera fácilmente, ahora al menos solo es el cargador EFI el que va a FAT.
#9 Como ya he dicho, en OpenBSD va a así y funciona de lujo, con el resto de la particion a6 como softraid y dentro cifrado todo.
Y de forma mucho más simple, en Linux con LUKS, cryptsetup y LVM queria morirme.
#10 Yo ya he hecho un montón de configuraciones como las que describes. No sé qué tipo de problemas tendrías pero a no ser que lo necesitaras en arm64 con EFI por ejemplo no te debería ser tan infernal.
#11 Tras usar OpenBSD para cifrar discos, Linux tiene la misma usabilidad que intentar grabar películas con un VHS en los 90.
#12 ¿por qué dices eso?
#16 En los BSD y sobre todo OpenBSD todo está hecho como un bloque.
O sea: para solucionar el problema de que el initramfs no es verificable por secure boot (razon por la vual se usaban firmas gpg en grub y demas), vamos a meterlo todo en una sola imagen.
Desde mi punto de vista, esto solo va a servir para aquellos que se instalan linux y quieren depender solo de las actualizaciones que le de la distribucion que se hayan metido. Cualquier individuo/empresa que este interesado en esto ya habra buscado sistemas con TPM, y dado que desde el kernel 5.10 los auxiliares como initramfs ya se pueden medir en el PCR 13, lo que Poettering viene a proponer no soluciona/mejora nada.
#5 a gente como tu, tal como explico en #13, esto no le sirve para nada. Si quieres verificar tu initram, a dia de hoy y con kernels nuevos, tienes que fijarte en el PCR 13 (o firmar initramfs con gpg y validarlo con grub, pero eso te ata a grub). Eso tiene un problema cuando haces una actualizacion si tienes un secreto en el TPM que depende de ese registro (y del 4): tu secreto esta protegido por un estado que no va a darse en el siguiente reset, y despues de leer ese secreto ya has extendido los registros para evitar que se pueda leer otra vez hasta el siguiente arranque. La unica manera de solucionar eso, pero tiene algunos flecos, es haciendo un replay del log de eventos en el TPM y extendiendo los registros con los hashes correspondientes, de manera que desde un estado verificado puedas calcular los hashes de las politicas de cifrado del sistema en el siguiente arranque. Hay gente de tpm-tools haciendo cosas en ese sentido pero esta todo un poco verde.
#14 Yo iba por otro lado. Los que metemos cosas raras en el initrd ahora lo hacemos de manera automática. Escribes triggers personalizados en el árbol de initramfs-tools (o de dracut, para el caso), añades los archivos que necesitas y las actualizaciones simplemente funcionantm. Con este sistema sería un dolor de cabeza automatizar los parcheos.
#15 justamente, por eso no sirve para gente como nosotros. En nuestro caso, solo podemos tratar de ayudar a los de tpm-tools para poder calcular el estado futuro del PCR 13 a partir del initramfs que acabamos de generar, y usar el TPM como verificador.
#13 Ozú no se me había dado cuenta de quien hace la proposición
. Bueno, espero que ésto no sea algo parecido a lo que hizo al implantar systemd de tratar que todas las distribuciones por "eggs" usen su sistema init 
No se como se llevaría esto con las imágenes initramfs personalizadas que usamos algunos, o como se montaría una alternativa para hacer lo que ahora hacemos así.
Por cierto que ya existe otra forma de proteger el initrd que es metiéndolo en una partición cifrada y abriendo esa partición desde Grub.
#1 ¿Lee las especificaciones? Las tienes al final del artículo
#2 Ya las estaba leyendo, y solo dice esto:
[TPM PCR 13 shall contain measurements of additional extension images for the initrd, to enable a modularized initrd – not covered by this document]
Y tirando de ese hilo, tampoco dice gran cosa.
#1 No creo que se pueda desde UEFI. Antes, con MBR se podia poner el OpenBSD con todo el disco cifrado.
Ahora en UEFI debes poner un cargador EFI en la particion FAT32 correspondiente.
https://www.openbsd.org/faq/faq14.html
En "If you use GPT for UEFI booting, do:" se ve. Crea una particion /dev/sd0a con todo el disco de tipo RAID, lo cifra y ahi ya crea los slices ("particiones") en Linux. Que no son "particiones", si no subdivisiones de una particion OpenBSD para GPT hecha con disklabel. En MBR funciona igual.
#3 Se puede más o menos, pero el cargador UEFI siempre está visible. También es el apaño que se usa para discos externos arrancables, que además del binario EFI para Grub también llevan un Boot portable.
El resto del disco se puede cifrar completo, pero el soporte en Grub para LUKS2 está un poco en pañales. Así que de momento hay algunas limitaciones.
#7 Como digo en OpenBSD está el loader EFI y luego puedes tener tu particion GPT (OpenBSD a6 en gptdisk/fdisk) cifrada completa como softraid que el cargador la descifra, arranca y monta.
Linux antaño era mucho mas inseguro por ello, era casi trivial saltarse la protección de arranque.
#1 En OpenbSD:
https://man.openbsd.org/boot_amd64.8 -> https://man.openbsd.org/boot.8
¿Y esto funcionaría en sistemas sin UEFI? Como Coreboot, Libreboot, U-boot, y los distintos arranques sin bios UEFI en sistemas de la arquitectura ARM.
No sé muy bien qué significa, pero sin duda acerca a Linux a su año en el escritorio.