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

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 19:59 UTC (Mon) by hummassa (guest, #307)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by mirabilos
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

No EFI is good. It's a better, more configurable, more flexible BIOS. Secure boot, OTOH, is a vendor-locking steaming pile of crap, even if it is well-implemented.

to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 20:27 UTC (Mon) by raven667 (subscriber, #5198) [Link] (6 responses)

> Secure boot, OTOH, is a vendor-locking

While it can be used that way by a hardware vendor, and we can call out those vendors and models for shame, that is not the only way this tool can be used and it is not the way it is used in the Linux/x86 world. You can be the owner of your machine, as described in the article.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 2:43 UTC (Tue) by hummassa (guest, #307) [Link] (5 responses)

The article is a Jailbreaking guide! Read one of those, re-read the article, and think!

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 5:05 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

I really don't think that this qualifies as "jailbreaking", using the standard tools to edit the system keys in the normal way, as you aren't breaking any security restrictions by doing this, you're supposed to be able to edit the keys. There is a similarity to jailbreaking guides, they both involve performing a sequence of technical steps around the early boot environment, but that's where the similarity ends.

I tried looking around for other jailbreak info for iOS but wasn't able to find much useful technical info as to what exactly the boot process is, what is broken in it to allow for an untethered jailbreak and how that is persisted across reboots. Anything that requires a USB connection or for the device to be tethered to boot isn't very interesting and isn't really the kind of threat that Secure Boot is meant to address. Secure Boot is meant to prevent remote attackers from modifying the early boot process in an undetectable way.

http://mjg59.dreamwidth.org/13061.html

A detailed comparison of different platforms such as iOS, Android, PS3, Xbox, uEFI Secure Boot would be interesting. Most of the boot locking systems have different design goals and threat models than Secure Boot so the techniques used by each may be different with different strengths and weaknesses.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 18:39 UTC (Tue) by hummassa (guest, #307) [Link]

> There is a similarity to jailbreaking guides, they both involve performing a sequence of technical steps around the early boot environment, but that's where the similarity ends.

It is all that is needed. I only see "secure" boot as effective in forcing jailbreak-like activities and steps on users that want to exercise the liberty of changing their operating system, usually for a better option for them.

It still seems to me that "secure" boot, even if succeeding in locking the core OS to be loaded -- which is doubtful at best --, does not add anything but Zero to the security of the system in general and, in particular, does not preclude the installation of programs that would steal keystrokes, passwords, or files, or that provoke unwanted hardware interactions.

If you really cannot see that, we will have to agree in disagreeing... after all, I cannot force you to be right. :-D

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 9:49 UTC (Tue) by mirabilos (subscriber, #84359) [Link] (2 responses)

This does not matter. It’s a closed platform, restricted, and besides the ability to take over your own machine works only for amd64, not for ARM, if it’s Microsoft® certified.

Just boycott this crap.

Who wants a several-Mebibytes long shitload of EFI, when a BIOS is just enough to boot a proper operating system?

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 17:22 UTC (Tue) by raven667 (subscriber, #5198) [Link]

You contradict yourself, machines where you control the keys are not restricted or closed...

I fully agree that it's reasonable to prefer open devices, you don't have to buy an MS Surface, get a Nexus 7 where you can replace the OS. If you don't want closed crap, don't buy it, there is a big enough market for open devices for them to remain available.

As far as EFI, I would ask which environment firmware and bootloader developers prefer, the impoverished environment of a 1980's era BIOS kernel or the more modern, comprehensive tooling of EFI (and GPT and dedicated boot partitions, etc. ad infinitum).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 18:39 UTC (Tue) by khim (subscriber, #9252) [Link]

Who wants a several-Mebibytes long shitload of EFI, when a BIOS is just enough to boot a proper operating system?

Apparently the answer is anyone who wants to use recent Intel's CPU (scroll down to Closed bits and open bits and then further to bits about Management Engine).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 13:41 UTC (Tue) by drag (guest, #31333) [Link] (20 responses)

> No EFI is good. It's a better, more configurable, more flexible BIOS.

No EFI is terrible. It's a bigger, more complicated, and more-everything BIOS.

It's BIOS++. It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

The only thing we need or want as Linux users is something in the computer smart enough to initialize the first few K of a select-able boot device to execute the first stage bootloader. Anything more complicated then that is just gives us more potential for headaches and bugs.

Secure boot is the only meaningful enhancement that I am aware of. I am not convinced that it's done well enough to be useful, but if it can be made to be useful then giving the end user the ability to control the keys negates any possible 'vendor lock-in' that we have to worry about.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 17:15 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> It's BIOS++. It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

I don't know about that, while it's doing the same task of initializing the hardware, it is doing so using much more normal, modern tooling without some of the restrictions of the 1980's BIOS as OS kernel. It's restricted by the task being accomplished and not the impoverished environment.

I would ask BIOS/uEFI, firmware and bootloader developers which environment they prefer as they are the constituents who are most affected by the design.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 17:20 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

It's probably at least partially Stockholm syndrome, but UEFI is (mostly) easier to work with from the bootloader side than BIOS was. The main problem is that we had 30 years of accumulated experience in which bits of BIOS were expected to work and don't have that level of expertise with UEFI yet, and so we trip over rather more bugs or unexpected behaviour.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 20:38 UTC (Tue) by Wol (subscriber, #4433) [Link]

A lot of operating systems completely ignore the bios once they've loaded. That to me, seems a pretty sensible and simple approach. Works fine.

The only thing that UEFI has in its favour is that it does provide protection against root kits - if done properly. Given the mess that is usually done, what's the betting we start getting rot-kits that exploit the UEFI real soon now ...

Cheers,
Wol

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 12:59 UTC (Wed) by nye (guest, #51576) [Link]

>I would ask BIOS/uEFI, firmware and bootloader developers which environment they prefer as they are the constituents who are most affected by the design.

From my selfish end-user perspective, I very much like that with UEFI my boot time is no longer dominated by the time spent before even reaching the boot loader. To be honest, that's the only quality I've ever cared about in a BIOS.

(Of course, there's still room for improvement!)

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 18:43 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

It's a massive increase in complexity with no payoff other then having a facier GUI for configuring your boot devices.

The other payoff is the ability to use latest and greatest Intel's CPUs. You can say a lot of "shoulda coulda woulda" words, but in the end the situation is very simple: if you want to use modern CPU then you need to use multimegabyte binary-only EFI modules provided by Intel. There are no alternative: either you use them or you don't get to play with shiny new CPUs.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 16:50 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

Uh... EFI-supporting BIOSes can also boot in BIOS mode for backward compatibility, and (obviously) still boot the Management Engine long before they make the decision to do that. (My current desktop is booted in just that way, as is the desktop of most Linux users using recent processors, and most existing Windows users on such machines.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 20:33 UTC (Mon) by etienne (guest, #25256) [Link] (1 responses)

Are all EFI PC able to run the EFI stack, init the memory and processor, and reboot to BIOS if they detect the user wants to boot the BIOS way (for instance to run an El-Torito CDROM), or are they loading the EFI stack and try to simulate a real mode BIOS - and then good luck if you try to run memtester which would overwrite the EFI code.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 21:26 UTC (Mon) by khim (subscriber, #9252) [Link]

Are all EFI PC able to run the EFI stack, init the memory and processor, and reboot to BIOS if they detect the user wants to boot the BIOS way (for instance to run an El-Torito CDROM), or are they loading the EFI stack and try to simulate a real mode BIOS

Usually it's a combination: they start as EFI and then at some point switch to old real mode BIOS+SMM code mix.

And then good luck if you try to run memtester which would overwrite the EFI code.

YMMV: some will survive memtester (if they keep the important bits hidden away in SMM), some may crash — especially when USB is involved (the first example Google found).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 25, 2013 20:42 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

EFI-supporting BIOSes can also boot in BIOS mode for backward compatibility

"EFI-supporting BIOS" is an oxymoron. Most such BIOSes are, in fact, thin BIOS emulation shims on top of the real thing: EFI-based firmware.

and (obviously) still boot the Management Engine long before they make the decision to do that

Yup. They start as EFI and then pretend they are BIOS. This combines worst sides of EFI and BIOS approaches but makes older OSes happy if you are lucky. It still means that without EFI your hardware will not boot.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 26, 2013 15:38 UTC (Tue) by nix (subscriber, #2304) [Link]

That entirely depends on what you mean by 'without EFI'. From my POV, in BIOS mode, my motherboard's EFI is just an implementation detail used by very early boot, of no interest once software I can control is running: among other things, I don't need an EFI partition, an EFI bootloader, or any of the other EFI PE stuff. It might as well be an old-style BIOS from my perspective. (The sensors don't work, but that's got nothing to do with EFI and everything to do with a sensor vendor and motherboard vendor who refuse to release any information on the sensor chip: each refers you to the other for info and neither will give you any).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 1:12 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (9 responses)

What about the ability to boot off (and address the partitions) of drives larger than 2TB?

Bottomley: Owning your Windows 8 UEFI Platform

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

I seriously hope you’re not using BIOS calls for that. That’s just… arrgh.

Basically, you put a good enough 32-bit bootloader into front which the 16-bit BIOS can then load. Easy.

(Even so, there *is* LBA48 support in BIOSes new enough. Otherwise, just bang the I/O ports. I think GNU GRUB can probably do that.)

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 20:17 UTC (Thu) by raven667 (subscriber, #5198) [Link] (7 responses)

GRUB isn't the BIOS/firmware, its a bootloader. If you made GRUB part of the BIOS/firmware and add the requirements for initializing the hardware then what you would get would look like EFI. Your suggestion is an argument against the BIOS not in favor of it, since it clearly doesn't have the features you want since your first inclination is to load something else. There is no architectural benefit to building your full featured environment on top of the BIOS rather than just replacing it and providing a BIOS compatibility layer, which is what EFI does.

Bottomley: Owning your Windows 8 UEFI Platform

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

No because GNU GRUB is just *one* implementation, and I have my own – BSD boot(8/i386) if you care.

And all implementations have a not too small, not too big set of things to work with and full machine control, unlike with EFI (one early but big #FAIL of it being that Apple machines run a 32-bit EFI which then can only boot a 32-bit kernel, not a 64-bit anything; couldn’t happen with BIOS things, as long as the machine is amd64 capable; this led to Apple supporting running 64-bit userspace with a 32-bit kernel, now isn’t *that* schizo?) which offers so many services that you can, but also *have* to use, and disables or actively breaks direct hardware access and other, older methods of doing things (BIOS is compatible down to 1981 – assuming you’ve got a 5¼" floppy somewhere, I do).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 21:52 UTC (Thu) by raven667 (subscriber, #5198) [Link] (5 responses)

Does a modern chipset even have the appropriate interface for plugging in a 5¼ floppy? Is that anything other than dead code? I actually have used a 5¼ floppy drive in the last year, with a USB interface, not direct connected to the motherboard.

If you had to design the firmware for a modern machine would it look anything like the BIOS? Or would it look more like EFI or GRUB with a command interface and a standard way of driving graphics, input, disk and network devies in a modular way.

Why does a high-capability bootloader even need to exist, shouldn't the machine just be able to load your OS kernel directly?

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 22:14 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

I’d probably design something a bit more featured than a BIOS, but definitely not as much as EFI. No command shell either, but definitely something that supports a serial console as first tier input/output like Sun OpenBOOT does.

Or I’d just use OpenBOOT. I mean, OpenFirmware existed, and was used left and right in the industry, before EFI came to be. It’s not without its own problems (such as, initialising only the first four megs of RAM on my SPARCstation) but not as crazily huge either.

Bootloaders are extensible. New filesystems. Network boot, even http. iSCSI. AOE. nbd. New operating systems. Co-processors that turn a computer of one architecture, say an m68k Amiga, into something entirely different, such as a PowerPC machine (those cards do exist and are supported by Linux, so this is not just speculation, although I’ve not seen something similar for PCs in the last decade; I don’t limit my horizon to PCs though).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 23:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]

So its definitely not the functionality of EFI that you are objecting to, since OpenBoot has much the same functionality, a CLI, etc. it's the specification or the implementation of EFI that you object to?

I don't know much about it but I can guess at the reasons why Intel decided to create EFI rather than extend OpenBoot, it may not have been available at the time or the firmware developers may not have wanted to work with Forth. There are probably other, technical, reasons why Apple didn't port it to x86 and ported EFI, which had been Itanium only, instead.

I don't have a strong opinion on the EFI implementation but I think we both agree that it has the infrastructure to solve the problem in a better way than the BIOS. Or maybe we disagree what the problem space is?

shouldn't the machine just be able to load your OS kernel directly?

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

How will it know where to find the kernel?

More to the point, how will the bios be able to tell the kernel all the important options it needs to know?

Your bios will be like LILO (which had to be re-installed every time you made a change to the kernel). Or like CP/M (which had to do a "sysregen" every time the hardware changed).

Cheers,
Wol

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:15 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Well this horse might already be out of the stable with UEFI but creating a way to make variables available to the kernel image doesn't seem impossible, maybe stored as EFI variables in a standard way, or as files on the boot filesystem. How did HPUX boot? That's what EFI was designed for. Maybe the tools aren't there now because there wasn't enough participation by Linux vendors or the Linux Foundation when these issues were decided, no one is going to hand you a seat at the table for these kinds of things, you have to insert yourself worth force if you don't want to be run over.

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:35 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

EFI has that information stored in the nvram boot variables.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 4:39 UTC (Wed) by pabs (subscriber, #43278) [Link] (12 responses)

Both UEFI and BIOS are non-free software, both are bad for user freedom.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 7:00 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

UEFI is free software, released under a BSD license. Most of the underlying platform initialisation code is non-free, and most shipping implementations of UEFI are non-free. Coreboot can be shipped under GPLv2, and so the overwhelming probability is that many vendors would ship it in a manner under which you could never exercise any of your freedoms.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 20, 2013 14:22 UTC (Wed) by mirabilos (subscriber, #84359) [Link] (10 responses)

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...

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

Bottomley: Owning your Windows 8 UEFI Platform

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

> No EFI is good. It's a better, more configurable, more flexible BIOS.

EFI is certainly more complex than BIOS, and assumes a lot more things.
What I see as bad points:
- there is a different version for 32 bits and 64 bits
- it shall know what to do when low level things are not working perfectly, for instance the hard drive is failing (I want to boot off a CDROM to salvage what I can), some hard disks are locked by password or have a special HPA locked (I want to boot off a CDROM/USB to unlock the hard disk containing secured information)
- it is too late to run memory tests if you already are using tens of megabytes of memory, the memory error may be in what you are using.
- if I remember well, it assumes one of the two modes of paging available to amd64, with no way to switch to the other one (my bootloader would not switch to 64 bits because of that)
- last time I read, EFI did not have a mouse interface and the BIOS has it (mouse at the bootloader level)
- Accessing the video card in graphic mode seems difficult when your discrete video card is plugged in in a PCIe slot and has only a BIOS interface in its video BIOS (also located on the video card).
- running in 64 bits means you can no more check you are on a real hardware, for instance checksuming the FLASH is no more possible - rootkit interception is too easy.