394 meneos
2654 clics
LinuxBoot para servidores: bienvenido al código abierto, adiós UEFI propietario (ENG)
LinuxBoot es una alternativa de código abierto para el firmware propietario UEFI . Se lanzó el año pasado y ahora los fabricantes líderes de hardware lo prefieren cada vez más como firmware predeterminado. El año pasado, LinuxBoot recibió una calurosa bienvenida en la familia Open Source por parte de The Linux Foundation.
|
comentarios cerrados
¿coreboot y LinuxBios no son el mismo proyecto? Y creo que LibreBoot es un fork de coreboot sin binarios. Eso reemplaza la Bios.
¿Y esto es un proyecto paralelo para reemplazar el UEFI?
Aunque creo que se entiende bien.
Sí. Ya van 3 o 4 proyectos para lo mismo.
UEFI ES UNA MIERDA DE DIMENSIONES CÓSMICAS.
Según el gráfico sería arrancar uefi o coreboot y le dan paso a linuxBoot y luego arranca el sistema operativo. LinuxBoot es también más rápido en el arranque.
No está entre el UEFI y el sistema operativo. Forma parte de lo que actualmente es el UEFI.
El diagrama lo deja bien claro. LinuxBOOT sustituye el payload del UEFI/Coreboot/u-boot. LinuxBOOT reside en la misma memoria SPI Flash del UEFI/Coreboot/U-boot. Sólo que el payload es distinto: LinuxBOOT en vez de UEFI DXE.
blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-in
UEFI boot officially has three phases (SEC, PEI and DXE). However, the DXE phase is divided into DXEBoot and DXERuntime (the former is eliminated after the call to ExitBootSerivices()). The jobs of each phase are
SEC (SECurity phase). This contains all the CPU initialisation code from the cold boot entry point on. It’s job is to set the system up far enough to find, validate, install and run the PEI.
PEI (Pre-Efi Initialization phase). This configures the entire platform and then loads and boots the DXE.
DXE (Driver eXecution Environment). This is where the UEFI system loads drivers for configured devices, if necessary; mounts drives and finds and executes the boot code. After control is transferred to the boot OS, the DXERuntime stays resident to handle any OS to UEFI calls.
Después de esto se lee el primer sector de disco como siempre se ha hecho, pasando el control al cargador del sistema operativo.
cc #6
ACPI es bastante simple: www.intel.com/content/www/us/en/standards/processor-vendor-specific-ac
"El problema" que hay será con algunos componentes hardware que no están bien diseñados. Pero esto es como culpar al premio novel de física de que a mi hijo en el colegio no le enseñan mecánica cuántica.
Por otro lado ACPI es solo una pequeña parte. Es como decir que un tesla es un coche de mierda porque las pinzas de freno son rojas.
UEFI no ha solucionado nada, y sólo ha añadido una capa de complejidad más al proceso de configuración y arranque de un sistema operativo en una máquina.
Y además da la posibilidad al OEM del equipo de decidir en TÚ MÁQUINA que sistema operativo puedes correr o no.
Y por favor, no me digas que TPM se puede deshabilitar porque sólo faltaba...
El regustillo que me quedo de uefi es que era como una "bios mas moderna y segura" (mensaje marketiniano) pero controlada por MS. Y que eso suponia que a efectos era más dificil instalarte otra cosa que no fuera windws. incluso que los creadores de SO tendrian que pagar algo para poder arrancar en hardware que la llevase.
Por otro lado, sobre el arranque de Linux, yo ya me pierdo...¿Cuantos niveles hay ya? Esta la bios/uefi, los coreboot, y demas historias que comentais, luego esta el lilo/grub, despues el kernel, despues el systmV/systemd, los inicializadores (gráficos (statx/kdes/gnomes, etc) y otros... ¿Supuestamente cada vez es mas rápido el arranque? Pues no me lo explico, sera porque metes un i9 overcloqueado.
Por otro lado, yo siempre he tenido problemas instalando en equipos con uefi. Al final siempre lo logro pero es cosa de probar hasta dar con la combinación correcta porque de entrada rara vez funciona.
Venga, hombre. Si no sabes no hables.
Otro problema muy usual con windows es que falle el disco duro. Quieres cambiarlo y resulta que el instalador no crea correctamente la partición EFI. Una vez tuve que pinchar el disco por USB en un linux para fabricarle a mano la partición EFI.
Donde se notará mucho el tiempo es en la parte de servidor. Las máquinas Unix hace mucho que tiene firmwares equivalentes a UEFI. Más complejos incluso. Por ejemplo depende de como estén conectadas las systemboards con el mismo hardware puedes tener un chasis con más procesadores o memoria, o menos, los cajones con las tarjetas de Red y otro hardware están asignados a una systemboard u otrá, etc... Y eso hace tiempo decidieron que eso se tenía que hacer por software en lugar de tener que entrar al datacenter a quitar una tarjeta de red a un servidor y ponérselo a otro, sin rebotar las máquinas. Eso si, los firmwares de máquinas Unix tienen las mismas pegas que las UEFI propietarias. Están protegidas por secretos industriales, con lo que la falta de escrutinio hace que el suministrador te la pueda meter doblada y los bugs se corrijan tarde o nunca.
Obviamente son más pasos que para arrancar desde BIOS, porque UEFI es infinitamente más compleja.
BIOS hacia un chequeo de Hardware muy elemental y comenzaba el arranque del sistema operativo leyendo el primer sector del disco que le dijeras.
BIOS era completamente cerrado y todavía hay partes que los que trabajan en proyectos libres aún no saben que hacen.
Habia solo dos o tres suministradores de BIOS, actualizarla era un engorro porque solías necesitar utilizar una disquetera (la mayoría de BIOS no sabían leer pendrives o discos Sata sin alguna actualización) y a demás los fabricantes de BIOS solían tener cogidos pornos huevos a los fabricantes de placas.
Sin tener en cuenta que aunque es un mecanismo sencillo como un sonajero (visto por fuera) por dentro no lo es y dependía completamente del chip de BIOS.
Cualquier atacante con acceso físico a la máquina podía instalar alguna actualización de hardware o de microcódigo. Si la BIOS tiene password pues le quita la pila y respetes lonque esta guardado en la CMOS y listo.
Por otro lado, deberías enlazar esto, que si son las especificaciones y no en enlace que has puesto:
www.acpi.info/DOWNLOADS/ACPIspec50.pdf
1000 paginitas con perlitas del tipo:
"This section describes the format of the Multiple APIC Description Table (MADT), which provides OSPM with information necessary for operation on systems with APIC, SAPIC or GIC implementations. ACPI represents all interrupts as "flat" values known as global system interrupts.
Therefore to support APICs, SAPICs or GICs on an ACPI-enabled system, each used interrupt input must be mapped to the global system interrupt value used by ACPI. See Section 5.2.13. Global System Interrupts,” for a description of Global System Interrupts.
Additional support is required to handle various multi-processor functions that implementations might support (for example, identifying each processor's local interrupt controller ID). All addresses in the MADT are processor-relative physical addresses"
Como ves, no es algo tan trivial.
Sobre el arranque en linux también depende de qué tipo de boot uses . En principio las distintas etapas de arranque de linux van tras la bios o UEFI de turno (siendo la bios/UEFI la encargada de arrancar la máquina y luego ceder el control al SO). El número de etapas que se usa suele ser dos, una que monta un minisistema con los drivers de los distintos filesystems necesarios para cargar la imagen de sistema (lo que nos permite arrancar linux en filesystems tan dispares como ext4, brtfs, zfs, xfs, ntfs, etc) y luego el arranque del propio sistema. Pero hay sistemas de arranque que aprovechan algunas ventajas de UEFI para eliminar una de estas etapas o gestores de arranque que tienen más etapas aún (cada uno con sus ventajas e inconvenientes) o directamente usan UEFI (que puede programarse en cierto modo para que en los arranques se comporte de un modo u otro... otra cosa cuestionable de una UEFI, tiene elementos escribibles y por lo tanto, manipulables y en caso de bugs, puede ser causante de intrusiones -las uefi… » ver todo el comentario