Bottomley: Owning your Windows 8 UEFI Platform [LWN.net]

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 14:22 UTC (Wed) by mirabilos (subscriber, #84359)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by pabs
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

Personally (not speaking for Debian) I don’t care much for firmware freeness (as I consider it mostly hardware) as long as it doesn’t step onto my toes. A BIOS is border-zone as it contains the BIOS Setup, which I interact with, but since I don’t use that all that often I live with it (although I did try to binpatch the one from a laptop of mine).

EFI is worse: big like hell, buggy like hell, new, shiny and loud, and not backwards-compatible. The addition of Digital Restrictions Management is just another contra. The freeness of the software (yes I *am* a BSD person) doesn’t help there any.

To link to Mako (I seem to be doing that *a lot* recently): http://mako.cc/copyrighteous/freedom-for-users-not-for-so...

to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 19:27 UTC (Thu) by zlynx (guest, #2285) [Link] (9 responses)

Probably the only reason you think BIOS isn't buggy is because it is so difficult to change anything.

In BIOS there's limited amounts of RAM available and it all has to be written in 16-bit assembly, some of which can't use *any* RAM because it hasn't been initialized yet.

EFI isolates those nasty bits and allows programmers to write pre-operating-system software again. Yes that means bugs, not because of EFI but because of crappy programmers.

You may as well rail against Python, Ruby, Java and C# (I do!) because they allow crappy programmers to write software that runs (badly) instead of immediately crashing.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 19:39 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (8 responses)

Some of your statements, such as being limited to 16-bit mode, are objectively wrong.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 23:01 UTC (Thu) by zlynx (guest, #2285) [Link] (7 responses)

Do you have a specific example of a BIOS implementation that switches the CPU to 32 or 64-bit protected mode? I am not aware of any.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 23:23 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (6 responses)

I did not say that, although there are the 32-bit BIOS extensions that all modern BIOSes implement (not always successfully), and many BIOSes use a 32-bit mode internally (sometimes leaking through by them forgetting to save the upper 16 bit of the 32-bit CPU registers).

I was talking about being able to use a 32-bit or 64-bit CPU mode *and* calling the BIOS at the same time. I know our bootloader does that. (No multitasking while “the kernel” (the BIOS) is in use, though.)

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 22, 2013 0:47 UTC (Fri) by zlynx (guest, #2285) [Link] (5 responses)

OK. But I was talking about writing the BIOS itself. The code running in the BIOS itself has, until EFI, been limited to 16-bit real mode.

In the past that has made it quite difficult to write HTTP download clients that fetch the operating system or firmware updates, mouse driven boot GUIs and the like.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 22, 2013 9:59 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

The code running in the BIOS itself has, until EFI, been limited to 16-bit real mode.

You are woefully out of date. The code running in BIOS was confined by the 16-bit real mode long-long ago, but for the last 20 years at least it's not limited by that at all. Only tiny piece of BIOS is actually implemented in that mode and it's mostly used to call the "real" multimegabyte thing.

You apparently know nothing neither about modern BIOS nor about EFI thus I find it puzzling that you feel that you can have meaningful discussion about them.

BIOS-to-EFI transition is much less abrupt then it feels at first glance: basically EFI just removes thin shim of IBM-PC BIOS style between real BIOS and OS and exposes the data structures BIOS writers used for years to OS directly.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 22, 2013 18:52 UTC (Fri) by zlynx (guest, #2285) [Link] (3 responses)

I'm not sure we're talking about the same things at all.

Grab a copy of your BIOS. Disassemble it. How much of it is in 16-bit real mode code and how much of it is in 32-bit protected mode code? Last time I did this, probably 10 years ago, none of it was.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 22, 2013 22:43 UTC (Fri) by etienne (guest, #25256) [Link]

Well there was SMM for some time with its crappy interface (write ebx to port 0x20 and see all the registers changed) which I cannot call real mode even if it is .code16gcc. That thing handle hard disk emulation of USB drive, keyboard and mouse - which is not present in the standard BIOS in between segments 0xE000 and 0xFFFF.
I hope SMM has gone from EFI.
BIOS is not perfect neither with no standard support of network card (put a packet on the wire / read last packet from the wire) and no support for multiple screen/keyboard.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 23, 2013 15:32 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

How much of it is in 16-bit real mode code and how much of it is in 32-bit protected mode code?

Significant chunk of it is for SMM mode which is 32-bit unprotected code with full access to 4GiB of address space. You can compile code for this mode with [relatively] modern compilers, etc. Yes, it's still weird mode (that's why EFI is going with normal 32/64-bit protected mode), but it's not 16-bit mode and it's programmed in C, not in assembler which means that the message which started the whole discussion (in BIOS there's limited amounts of RAM available and it all has to be written in 16-bit assembly) is factually wrong as mirabilos pointed out.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Mar 1, 2013 1:09 UTC (Fri) by Wol (subscriber, #4433) [Link]

I thought that at least one MAJOR bios was not written in Assembler (and why shouldn't a bios be written in c?). It's written in Forth.

Which has the unusual property that a decently competent programmer can make the Forth object code smaller than the equivalent assembly! Excellent for the old BIOSes where the BIOS chip size was measured in Kb not Mb.

Forth is also unusual in that it is pretty near impossible to code a GOTO :-) Most other languages have a goto, even if it's not normally necessary or used.

Cheers,
Wol