Portada
mis comunidades
otras secciones
#32:
Creo que en esto hay un batiburrillo notable, favorecido por la poca idea que tienen de nada en Xataka.
La BIOS es un programa en EEPROM que se encarga de tres cosas: configurar el hardware, comprobarlo (POST) e iniciar el arranque del SO (bootsrap). También tiene su menú para configurar la máquina.
UEFI es un protocolo que sólo se encarga de iniciar el arranque del SO o cualquier otra cosa desde disco. El SO puede estar firmado (secureboot) o no, en principio no es obligatorio en UEFI.
Lo que todo el mundo asocia con BIOS y EFI son los menús de configuración del sistema. En el primero está en EEPROM y en el segundo en disco.
Intel va a quitar la EEPROM porque las funciones de configuración y comprobación del hardware ya las hace con el infame IME (Management Engine).
No tiene nada que ver con bits, es simplemente librarse del legacy.
La BIOS es un programa en EEPROM que se encarga de tres cosas: configurar el hardware, comprobarlo (POST) e iniciar el arranque del SO (bootsrap). También tiene su menú para configurar la máquina.
UEFI es un protocolo que sólo se encarga de iniciar el arranque del SO o cualquier otra cosa desde disco. El SO puede estar firmado (secureboot) o no, en principio no es obligatorio en UEFI.
Lo que todo el mundo asocia con BIOS y EFI son los menús de configuración del sistema. En el primero está en EEPROM y en el segundo en disco.
Intel va a quitar la EEPROM porque las funciones de configuración y comprobación del hardware ya las hace con el infame IME (Management Engine).
No tiene nada que ver con bits, es simplemente librarse del legacy.
#21:
Parece que el autor del artículo confunde BIOS con SETUP.
El SETUP es esa pantallita en la que ajustamos cosas, aunque cada vez menos.
La BIOS se encarga del arranque del PC y de llamadas estándar. Por ejemplo se puede llamara la disquetera para que lea un sector, o a la tarjeta gráfica (hasta la VGA) para que se ponga a determinada resolución de gráficos o texto.
El problema de la BIOS es que está muy anticuada: por compatibilidad, sigue funcionando en el modo real de 16 bits, con limitaciones como los famosos 640 KB de RAM (1 MB en total contando RON y memoria de gráficas y extensiones) cuando la mayoría de usuarios usan el de 64 bits (o todavía muchos el de 32 bit). Eso hace que los procesadores arranquen en modo de 16 bit y después se cambie al modo de 32 o 64 bit.
Una vez que el procesador ha cambiado a 32 o 64 bit la BIOS no vale para nada, así que esta absolutamente obsoleta y por eso ya la van a eliminar.
El siguiente paso supongo que será eliminar el soporte de 16 bit, lo que permitirá simplificar un poco el diseño de los procesadores.
El SETUP es esa pantallita en la que ajustamos cosas, aunque cada vez menos.
La BIOS se encarga del arranque del PC y de llamadas estándar. Por ejemplo se puede llamara la disquetera para que lea un sector, o a la tarjeta gráfica (hasta la VGA) para que se ponga a determinada resolución de gráficos o texto.
El problema de la BIOS es que está muy anticuada: por compatibilidad, sigue funcionando en el modo real de 16 bits, con limitaciones como los famosos 640 KB de RAM (1 MB en total contando RON y memoria de gráficas y extensiones) cuando la mayoría de usuarios usan el de 64 bits (o todavía muchos el de 32 bit). Eso hace que los procesadores arranquen en modo de 16 bit y después se cambie al modo de 32 o 64 bit.
Una vez que el procesador ha cambiado a 32 o 64 bit la BIOS no vale para nada, así que esta absolutamente obsoleta y por eso ya la van a eliminar.
El siguiente paso supongo que será eliminar el soporte de 16 bit, lo que permitirá simplificar un poco el diseño de los procesadores.
#8:
Con esto ya viene el control de software via Hardware, mañana el que no esta certificado no podra instalar software viva el TPM
https://en.wikipedia.org/wiki/Trusted_Platform_Module
https://en.wikipedia.org/wiki/Trusted_Platform_Module
Comentarios
Con esto ya viene el control de software via Hardware, mañana el que no esta certificado no podra instalar software viva el TPM
https://en.wikipedia.org/wiki/Trusted_Platform_Module
#8 De esto ya nos advertía Ricardo hace por lo menos 15 años.
Pero claro, estaba loco y se comía tranchetes de los pies.
Visionario. Siempre lo fue y siempre lo será.
#11 Stallman es como el Julio Anguita de la informática. Cada vez que dice algo nos parece una barbaridad y nos reímos de él, pero con el tiempo hay que darle la razón.
#16 Para mi que soy ateo practicante, Stallman es DIOS.
#11 #16 Si la gente atendiese a sus charlas, se daria cuenta que es un tipo muy razonable. El siempre ha dicho que lo de San Ignutius es una broma; ironia o sarcasmo. Pero en la red siempre le sacan sus tonterias personales que a mi, sinceramente me importan tres cojones. A mi me importa opinar sobre lo que promulga, que es lo que realmente me afecta. Mientras, los imbeciles le critican por su fisico o por su vida personal.
RMS es una de las personas no solo mas coherentes, sino mas consecuentes de la sociedad actual. La gente se olvida que fue profesor hemerito del MIT (a donde practicamente ningun ingeniero informatico o teleco puede llegar), que lo dejo todo por embarcarse para luchar por un mundo mejor, que tiene tantos commits en tantos proyectos, que hoy en dia GNU/Linux es asi, gracias principalmente a el. Tan solo en GNU/Emacs tiene mas de 20.000 commits, que son impresionantes. Influenciado por Noam Chomsky, ya que fue companero de oficina. Tuve el placer de conocerle en persona, hace unos anos cuando vino a Finlandia.
#8 Curioso, cuando he leído TPM he pensado que era "Tu Puta Máquina".
#12 "Maquina", claro, claro
#30 Por el tema de la noticia
#8 Esto no es correcto. UEFI tiene en opción el Secure Boot que es lo más parecido a lo que dices tú (sólo Microsoft firmaría el software que se puede instalar en una máquina).
Según lo sofisticada que sea la UEFI puede:
* Permitir desactivar el Secure Boot
* Añadir tus propias keys para poder firmar tus propios shim, grub, kernels
Porque Secure Boot no es lo mismo que Secure Boot haciendo caso únicamente de las keys de Microsoft (aúnque en el 90% de los casos es así).
Eso sí, parece ser que muchas máquinas ARM con Windows no llevan la opción para desactivar el Secure Boot.
Adiós al IBM-PC, que pasará a denominarse Intel/AMD64-PC
Parece que el autor del artículo confunde BIOS con SETUP.
El SETUP es esa pantallita en la que ajustamos cosas, aunque cada vez menos.
La BIOS se encarga del arranque del PC y de llamadas estándar. Por ejemplo se puede llamara la disquetera para que lea un sector, o a la tarjeta gráfica (hasta la VGA) para que se ponga a determinada resolución de gráficos o texto.
El problema de la BIOS es que está muy anticuada: por compatibilidad, sigue funcionando en el modo real de 16 bits, con limitaciones como los famosos 640 KB de RAM (1 MB en total contando RON y memoria de gráficas y extensiones) cuando la mayoría de usuarios usan el de 64 bits (o todavía muchos el de 32 bit). Eso hace que los procesadores arranquen en modo de 16 bit y después se cambie al modo de 32 o 64 bit.
Una vez que el procesador ha cambiado a 32 o 64 bit la BIOS no vale para nada, así que esta absolutamente obsoleta y por eso ya la van a eliminar.
El siguiente paso supongo que será eliminar el soporte de 16 bit, lo que permitirá simplificar un poco el diseño de los procesadores.
#21 Gracias por la aclaración, porque joder, yo me había quedado en plan, pues juraría que mi placa tiene uefi, y yo tengo que seguir presionando el f2 para entrar en el momento correcto y veo la plantilla de setup, a ver si es que me timaron
.
¿Ya han pedido permiso a la NSA?
#2 Precisamente es por eso, porque la BIOS de toda la vida no permite que la NSA instale "sus" modulos...
#3 Y a los que usamos Linux, la NSA nos espía por "extremistas". Señores, tenemos que usar los sistemas operativos desde la moderación.
#26 Estáis usando sistemas operativos por encima de vuestras posibilidades.
#3 Ya, jaja. si tu supieras
#2 Cuando dicen más seguro nunca significa más seguro para el usuario.
#5 Y no solo es el tema de la seguridad, a mi me ha causado un montón de problemas.. si instalas varios sistemas operativos en diferentes particiones y tienes que recuperar un grub a veces se convierte en tarea imposible..
#10 La mejor forma es arrancar desde una liveCD, lanzar un chroot contra la partición de Linux, y reinstalar desde ella el GRUB. Mano de santo.
#33 Tengo varias máquinas con mi propio gestor de arranque UEFI que cargan el cargador de arranque de windows pero si detectan la tecla L pulsada cargan el kernel de linux ( compilado como app UEFI, EFILoader creo que se llamaba la opcion ). Son como... no se, ¿ 100 lineas de codigo ? ( quiza menos por que este cargador tambien me hace otros trapis cuando arranco windows, como desabilitar firmado de drivers y mas cosas ). Y con esto, basicamente es renombrar bootmgfw.efi a bootmgfw.org en la particion de EFI en EFI Boot Microsoft y poner mi programa como bootmgfw.efi y el kernel compilado de linux como bootmgfw.lnx en el mismo directorio.
#39: Vamos, algo cómodo y accesible a todo el mundo, sobretodo en comparación con BIOS.
#60 Lo que decia en ese post era simplemente para dar a entender que UEFI es mucho mas potente, sencillo, etc. para hacer gestores de arranque; tan asi es que con poca cosa puedes hacerte gestores de arranque.
#10 Desde el punto de vista tecnico, en UEFI es muuuucho mas sencillo hacer multiarranque y demas, el gestor de arranque es una aplicacion ( un fichero PE ) que trabaja con una API mas o menos sencilla/limpia ( años luz de hacerlo con un sector de arranque que carga mas sectores de disco a pelo y hace virguerias para cargar el kernel de turno ) y carga otras aplicaciones o su binario de kernel o tal, es MUY sencillo.
#38: Pues a ver cómo soy capaz de arrancar un Live CD que en un P4 Prescott HT iba sin problemas.
#61 Pues si el LiveCD tiene arranque BIOS y tu maquina actual tiene modo compatibilidad con modo BIOS, activandolo. Si no, y es lo qye te recomiendo, creando un LiveCD con boot UEFI ( mejor bajarte la ISO y crear un pendrive de arranque en modo UEFI a partir de esa ISO ). A ver, que luego hay placas que, tanto en UEFI como en BIOS, son un poco tocapelotas... pero eso hay de todo en todo.
#10 Lo bueno de UEFI es que puedes meterle la ruta del fichero grub.efi como una opción de arranque o cargarla a mano desde la consola EFI dando un par de comandos.
mas monopolio para mierdasoft que es quien firma las uefis
#6 La firma es para poder arrancar un SO con secure boot activado y tú si quieres puedes desactivar el Secure Boot de la UEFI e instalar lo que quieras sin firmar.
#31 si te da esa opcion si, pero creo que no todas lo hacen.
#46 En dicho caso es culpa del fabricante, deberían darte la opción de desactivarlo.
#54: Ya, pero podrían decirlo al comprarlo, que estás adquiriendo un producto cojo.
Creo que en esto hay un batiburrillo notable, favorecido por la poca idea que tienen de nada en Xataka.
La BIOS es un programa en EEPROM que se encarga de tres cosas: configurar el hardware, comprobarlo (POST) e iniciar el arranque del SO (bootsrap). También tiene su menú para configurar la máquina.
UEFI es un protocolo que sólo se encarga de iniciar el arranque del SO o cualquier otra cosa desde disco. El SO puede estar firmado (secureboot) o no, en principio no es obligatorio en UEFI.
Lo que todo el mundo asocia con BIOS y EFI son los menús de configuración del sistema. En el primero está en EEPROM y en el segundo en disco.
Intel va a quitar la EEPROM porque las funciones de configuración y comprobación del hardware ya las hace con el infame IME (Management Engine).
No tiene nada que ver con bits, es simplemente librarse del legacy.
#32 Uhmmm si, pero ojo, si ves codigo de implementacion de UEFI ( del UDK de intel por ejemplo, del que parten muchas implementaciones ), ves que UEFI es todo, de hecho el programa de configuracion o setup es un modulo UEFI, los drivers de soporte para hardware son modulos UEFI, etc. UEFI es TODO, luego ahi hay diferentes agentes pero todos son modulos UEFI. Hay diferentes fases ( PEI, DXE, Boot ) y cada una tiene sus modulos ejecutables ( drivers, modulos para SMM, BDS, boot managers,... ), pero todo es UEFI.
Solo que hasta hace poco ( ya empiezan a desaparecer, y mejor asi ), habia hibridos BIOS UEFI que tenian todo esto pero usaban los CSM ( compatibility support module ) para poder arrancar en modo BIOS ( leer sector de arranque en vez de particion UEFI con UEFI boot managers ) etc. Incluso esta el modo arranque UEFI pero dejando habilitadas las llamadas a BIOS ( un chapuzon, pero W7, por ejemplo, aun necesita este modo... salvo que parchees cosas, pero eso es largo de explicar ).
#42 Si, pero UEFI no es todo-todo.
El programa de setup que está en UEFI es el menú del que hablaba, que ahora puede ser chulo y con muchos gŕaficos.
El setup y drivers que están en módulos de UEFI son de periféricos y sistema operativo.
La configuración a bajo nivel de la placa base no puede estar en disco. Antes de poder acceder al disco tiene que configurar la velocidad de la memoria, las tensiones o los rangos de DMAs, p.e. Esto lo hace el IME con la configuración concreta de cada placa base.
#47 El programa de setup, sea cutretexto o grafico, es o un modulo UEFI o parte del BDS que es otro modulo UEFI o parte de algo asi, pero modulo UEFI. UEFI es desde que arranca hasta que da control al boot manager del SO que sea. ( todo esto esta en la Flash ROM ).
Creo que confundes algun tema ahi: "La configuración a bajo nivel de la placa base no puede estar en disco" < nadie ha dicho eso ni ha dicho algo que implique eso. Los modulos UEFI que se cargan del disco son: boot managers o UEFI loaders, en algunos casos drivers UEFI ( pero no drivers de la fase DXE ). Todo eso que dices que "antes de acceder al disco tiene que...", claro, asi es, y eso ocurre en el codigo que se carga desde la EEPROM ( Flash ROM ) de la placa ( esos bonitos chips Winbond de 8 patas y generalmente 32Mbit o 64Mbit ), que son, la gran mayoria de ellos, modulos UEFI ( binarios PE como los de windows con ciertas caracteristicas y demas, pero binarios PE ).
Mirate si quieres las fases de UEFI: PEI, DXE, ...
Y no, nada de eso lo hace el IME. El Intel Management Engine hace otras cosas pero todo eso que dices lo hace tu CPU x86, parte ( muuuuyyy poca, la ultrabasica ) en modo real ( modo unreal/voodoo en realidad ), y el resto ya unos PEs de 32bit o 64bit, todos leidos de la Flash ROM y cargados en memoria y ejecutados por la CPU normal.
Hago desarrollo de cosas de estas, tanto algunos hacks a nivel de FlashROM ( en realidad compilar y flashear la Flash ROM, sin mas, no es muy diferente a hacerlo en binarios UEFI que se ponen en la perticion UEFI de disco, segun a que nivel lo hagas ) como a nivel de UEFI loaders en esa particion UEFI ( para hacks cargando Windows, Linux,... ).
#48 Evidentemente tienes más información que yo, aunque en algunas cosas estabamos hablando de lo mismo.
Desconocía las fases SEC, PEI y DXE, y entiendo que las dos primeras están en Flash. Pensaba que en Flash seguía estando un código similar al del BIOS de inicializiación y POST y luego saltaba a código UEFI, pero veo que UEFI incluye incluso las primeras de inicilización de la placa base.
https://github.com/tianocore/tianocore.github.io/wiki/PI-Boot-Flow
Gracias por la iluminación.
#53 Todas las fases, menos el paso de los uefi bootloaders ( y a veces drivers pero ya mas tipo drivers de sistemas de ficheros y demas, todo pre-SO ) esta en FlashROM, DXE tambien.
Hombre, al final hay cosas que tanto BIOS como UEFI tienen que hacer, inicializar todo, solo que en UEFI se hace lo miiinimo minimo y se pasa a modo protegido plano de 32 o 64 bit, y ya ahi se ejecutan drivers y otras inicializaciones ya en un entorno mas comodo/sano.
#53 Yo suelo meterme entre la fase BDS y la TSL ( en realidad suplanto el cargador de UEFI de windows o creo una entrada de driver en la nvram y hago que cargue un .EFI mio antes de pasar a cargar el SO; esta Bootmgfw.efi que carga winload.efi y este carga ntoskrnl.exe -en uno de sus diferentes nombres, generalmente ntkrnlpa.exe- ) y hago algunas virguerias para "montar la ola" de cambios que hacen esos binarios en todo el entorno y sobrevivir a toda la carga del SO y luego "coexisto" con Windows.
#57 Hmmmm... ¿Debería hacer un hash de la partición EFI y comprobarla cada vez que arranco en el ordenador de mi casa?
#58 O poner secure boot activarlo. Para que no cargue binarios que no esten firmados... eso si, que antes no te hayan inicializado y metido un certificado con clave publica correspondiente a una clave privada con la que luego firmen un binario malicioso... pero vamos, yo no hago nada malicioso, solo cosas que luego tienen utilidad/comodidad para algunos temas ( desarrollo drivers para NT y es comodo no tener que firmar drivers o arrancar en modo de firma desabilitada -cada dia mas incomodo en windows- y otros temas parecidos ).
Cierto, es tiempo de coreboot: https://www.coreboot.org/Welcome_to_coreboot
#18 Coreboot es una BIOS libre, como la BIOS, es de 16 bit, y como la BIOS, está obsoleta.
#22 Incorrecto, coreboot puede tirar de payloads para cargar una BIOS libre (o EFI) como por ejemplo, SeaBIOS: https://www.coreboot.org/SeaBIOS
TianoCore UEFI: https://www.coreboot.org/TianoCore
¿Obsoleto es entrar en 32-bit tras 10 instrucciones?
/cc #18
#23 En realidad #22 tiene razon. Una BIOS cualquiera puede cargar otra BIOS, una UEFI, o lo que te salga de ahi. De hecho, un gestor de arranque para maquinas con BIOS puede hacer eso mismo, al final es cumplir la cadena. Asi se han hecho muchos hackintosh hace un tiempo, con cargadores tipo BIOS en sectores de arranque que cargan una capa UEFI que luego llama al boot manager de OSX.
Bueno que intel elimine el soporte no indica el fin, hay mas frabricantes de placas y micros fuera de intel, yo llevo una decada sin tocar intel (menos en el portatil pero por que fue una ganga).
#4
Los PICs usados en los IBM-PC están integrados en los procesadores de Intel y AMD. Si Intel deja de montar los PICs y atenderlos las placas base podrán poner lo que quieran que no funcionarán.
#7 Si hace eso ¿no entraríamos en el la zona de monopolio forzando al resto de fabricantes a utilizar lo que tu quieras que se utilice?, si lo montas en AMD supongo que solo las placas para amd podrían seguir utilizando alternativas.
#9
Las plataformas Intel dejarán de soportar el modo real, y puede que abandonen por completo la segmentación de memoria como ya ocurre con AMD64.
AMD por su parte puede seguir implementado compatibilidad con IBM-PC. Todo dependerá de lo que obstaculice su diseño. Estas cosas tan antiguas son un lastre. Tanto en el hardware como en el software. Tienen bugs y formas de funcionar complicadas que han de reproducir para ser compatibles con software de hace 40 años.
#19 Hombre lo de la compatibilidad con software de hace 40 años lo puedes arreglar con virtualización, en sistemas avanzados puedes emular lo que te haga falta desde otro dispositivo y ahora si tenemos potencia para ello. AMD siempre suele dar un poco más de vida a tecnologías que intel declara obsoletas si está dentro sus posibilidades(recuerdo hace unos años como le dio vida a el socket7/super7 durante un poco más de tiempo).
#7 Siempre puedes emularlo en la propia BIOS mediante el System Management Mode: https://en.wikipedia.org/wiki/System_Management_Mode
#35
Eso también quedará eliminado.
#4 Intel hasta tiene acuerdo ya con ARM e incluso con AMD (despues de años de Nvidia) y eso que es la "competencia"
Sencillamente esto es el no es no aplicado a la informática
#14 Lamentablemente si parece ser así, cuando se promocionan tanto esos acuerdos para "compartir tecnología" y "fomentar la competencia" al final acabamos con cosas como esta, en la que se puede berrear todo lo que se quieras pero al final acabas tragando por que no te queda otra.
#14 Hombre... Buena parte del acuerdo con AMD es, básicamente: "Yo te dejo implementar la arquitectura intel32, y tú me dejas implementar la arquitectura AMD64". Sin ese acuerdo, Intel no podría fabricar procesadores compatibles con AMD64 (las extensiones de 64 bits actuales), y AMD no podría fabricar procesadores compatibles con la arquitectura de 32 bits de Intel de toda la vida.
#4 Si pero no, hay oproms y demas que estan escritas para modo real 16bit ( o para modo unreal/voodoo... ) para BIOS que las hace intel y se las da a esos fabricantes. Si intel deja de hacerlo... se acabo.
Pero bueno, mejor.
#4 Cuando eliminen el soporte para instrucciones de 16 bits entonces si que será el fin Y lo harán tarde o temprano, de hecho lo raro es que no lo hicieran hace años.
UEFI es una caquita que da problemas a lo que no sea Windows. Pero bueno... Yo cuando puedo tiro de AMD.
#17 Pues yo tengo instalado Linux en una máquina con UEFI (y micro AMD) y funciona perfectamente, no sé donde encontrais los problemas.
#49 Yo me he encontrado algunas uefi que son híbridas y si intentas instalar como UEFI casca y tienes que hacerlo como BIOS normal.
Me encanta leer comentarios de gente que se piensa que UEFI = Secure Boot.
Relacionada
Cómo desactivar Intel Management Engine (IME) [ENG]
Cómo desactivar Intel Management Engine (IME) [ENG...
wiki.gentoo.orgUEFI es el sistema más seguro para evitar que los usuarios puedan instalar lo que quieran en sus equipos. Instalar un sistema operativo que no sean el del gran hermano, en algunos equipos con la putamierdauefideloscojones, puede llegar a ser una odisea.
#24 No necesariamente... eso es el secureboot.
#27 Sip, en los primeros equipos que me llegaron me pasaba eso, hasta que me di cuenta. El software no es lo mío. Lo mío son las entrañas.
#24 Pues yo he instalado Linux en equipos con UEFI sin ningún problema, de hecho fue más fácil que instalar Windows.
A la mierda todo esto.
RV64G al rescate.