Weekly Edition
Return to the Security page
| |||||||||||||
Bottomley: Owning your Windows 8 UEFI Platform
James Bottomley describes
the process of taking control of a UEFI secure boot system.
"Even if you only ever plan to run Windows or stock distributions of
Linux that already have secure boot support, I’d encourage everybody who
has a new UEFI secure boot platform to take ownership of it. The way you
do this is by installing your own Platform Key. Once you have done this,
you can use key database maintenance tools like keytool to edit all the
keys on the Platform and move the platform programmatically from Setup Mode
to User Mode and back again. This blog post describes how you go about
doing this."
(Log in to post comments)
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 3:44 UTC (Mon) by heijo (guest, #88363) [Link]
An easier and better plan:
1. Disable Secure Boot 2. Business as usual
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 10:14 UTC (Mon) by dsommers (subscriber, #55274) [Link]
Which also reduces the security layer secure boot adds. But of course, security stuff is always so complicated so lets just turn everything off and hope for the best!
/me wonders if people have completely forgotten these good old boot sector viruses
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 11:31 UTC (Mon) by ekj (guest, #1524) [Link]
Secure boot makes essentially zero difference to the security of the average computer-user.
The things she cares about are trojans sniffing things like banking-details and passwords, and perhaps weaknesses in browsers or other exposed programs that leads to the PC becoming zombied.
Secure boot makes essentially no difference to any of this. If you've got a unpatched IE, or an outdated version of Java, or if you double-click everything you get in email, you're precisely as screwed with or without secure boot.
Of course the average PC-user also never changes OS, so secure boot would likely not even be noticed by her/him anyway.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 12:42 UTC (Mon) by dsommers (subscriber, #55274) [Link]
> The things she cares about are trojans sniffing things like banking-
True
> Secure boot makes essentially no difference to any of this. If you've
True too. But you then ignore that secure boot removes an attack vector. That attack vector has not been used as much as it was during the DOS times, where BIOS vendors after a while added features to block writes to the boot sector. Secure boot ensures that the core OS loaded is unmodified. Which can even be seen as an extension of this old "don't write to boot sector" feature.
Secure boot makes it in fact harder to modify the earliest code loaded on a system. If you get trojans, backdoors, keyloggers, etc loaded at the very earliest boot stages, it is also more likely you can hide that code from the end-user's additional security programs. This is the attack vector secure boot can defend against. And the reason such an attack might be possible, is due to lack of secure boot and not properly updated system with latest updates for OS, third-party software and anti-virus/anti-scam/anti-spam/anti-whatever software. Secure boot is an additional layer of security, not a replacement of anything else.
Sure the boot process might not be the easiest attack vector at all, but the end-user side is getting more and more attention through security products, making the currently used attacks harder. Secure boot is just filling a gap, a gap which is best solved hardware wise. And if nothing is done in this area, this is where more attacks will be diverted in the future. And with "nothing", I also include "disable secure boot".
For the end-user, such security mechanisms needs to stay out of their way. Just like firewalls. And that is the current standard. However, firewalls can be tweaked even better, which is not a task the average end-user might care for at all. But the firewall is there with a usually decent protection. Users interested in a higher security level can tweak this to make it harder.
Secure boot is a similar mechanism. Most users shouldn't ever notice it as, as you say, they won't change the OS. But for those who do change the OS; providing mechanisms to have a secure system, even through the boot sequence, is a good idea.
Remember all the fuzz and noise caused when Microsoft enabled the firewall by default in one of the Windows XP service pack? This discussion about secure boot is an iteration of that. But very few hardly complain about that decision nowadays.
But by all means, there are people who disables firewalls, SELinux, authentication mechanisms, etc, etc - and in the future secure boot ... For such users anything which says "increased security" will always be a hassle, no matter what it is, and it will be disabled. That attitude is a failure by default, IMO.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 19:53 UTC (Mon) by hummassa (subscriber, #307) [Link]
> True too. But you then ignore that secure boot removes an attack vector.
No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.
> That attack vector has not been used as much as it was during the DOS times,
This has a reason: while it may be practical in an embedded and usually homogeneous environment, in a standard-PC env, the attacker must have code to read every one of the one hundred different filesystems if he wants to compromise the system via boot. IOW, the attacker must be an entire OS.
> where BIOS vendors after a while added features to block writes to the boot sector.
This had not detained nor even slowed down malware at that time (yes, I am that old) and it was considered just a nuisance because it difficulted NECESSARY system updates; you know, to patch vulnerabilities &c... Many, many people turned this off in BIOS. Ah, and once you entered another OS, this was not effective because the other OS bypassed BIOS and talked directly to the hardware. THAT is the reason this is not in effect in today's PCs...
> Secure boot ensures that the core OS loaded is unmodified.
Yes. But from a security standpoint, this would ONLY be a good thing if the core OS loaded was PROVEN secure. If you load a swiss cheese of vulnerabilities, unmodified, this is a BAD thing.
> Which can even be seen as an extension of this old "don't write to boot sector" feature.
Yes. Equally uneffective, equally a nuisance, equally time-consuming for no good reason.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 20:21 UTC (Mon) by raven667 (subscriber, #5198) [Link]
>> True too. But you then ignore that secure boot removes an attack vector.
>No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.
Are you sure? Are you saying that there were jailbreaks that were permanent and that can't be removed or detected and that persist across reboots and upgrades of the OS? Are you sure it was the boot infrastructure that was being bypassed, rather than the OS kernel?
>> Secure boot ensures that the core OS loaded is unmodified.
That is an absurd position to take because you and I both know that the OS kernel is not and never will be "proven" secure, also this is not a claim which is being made by secure boot proponents or by the spec so to defend against claims which weren't made is the creation of a straw man on your part.
Secure Boot can only help prevent permanent, undetectable modification of the firmware and stage 1 bootloader by those not authorized by the system owner (such as malware), what the OS kernel and later code does with this known good system state is up to the implementor, usually they are going to want to push the known good state as far as they can (until arbitrary code which can be under the control of an attacker is run and re-compromises the system), by doing their own signature checking and whatnot.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 19, 2013 11:40 UTC (Tue) by drag (subscriber, #31333) [Link]
> Secure boot makes essentially no difference to any of this. If you've got a unpatched IE, or an outdated version of Java, or if you double-click everything you get in email, you're precisely as screwed with or without secure boot.
Kernel level root kits are now common place on both Windows and Linux. It's now 'script kiddie' level technology. Anti-virus and rootkit detector software is worthless at detecting these threats and it is a practical impossibility (ie: more work then it's worth) to 'clean' a system that has been taken over by these things.
Signed bootloader and kernels is a step in the right direction.
No point in going backwards when UEFI signing is under your control.
Secure boot Posted Feb 20, 2013 9:36 UTC (Wed) by man_ls (subscriber, #15091) [Link] I don't think that secure boot is a big improvement. For me (I want to run Debian on my machines) it is definitely more trouble than it's worth. Perhaps if you want to run stock Red Hat on stock hardware -- and that is the point: vendor lock-in. So thanks but no thanks.For the record, cleaning up an 0wned machine can be very instructive. I have had the pleasure of doing it on one client's machine and it was a very interesting experience: from the trojaned SSH to the spam sender to a script that (I suspect) tried to flood the connections of any white hat that tried to recover the machine (e.g. me). And as a bonus, something like 50 GB worth of vuln scan data gathered by the machine in its free time. After a huge upgrade, several scans and some very basic cleanup the problems have not resurfaced. Perhaps the intruders were not very good at their job.
Secure boot Posted Feb 21, 2013 16:46 UTC (Thu) by drag (subscriber, #31333) [Link]
There is no way for you to know that you cleaned up that machine properly.
That's the problem.
It's one thing to screw around with a 'owned' machine for your own bemusement, but it's quite another to actually get it to a point were you know it is secure.
With a kernel level root kit you must not trust any user space tools. This means that any sort of checksum utility or package checking feature provided by RPM or apt is completely worthless. Any anti-virus or root kit checker is completely worthless. Any access to any compromised binaries can be intercepted and redirected to their 'proper' versions. Payloads, directories, and volumes that potentially contain many GB of data can be easily hidden completely from the root user.
None of this is 'special' or '7331' features. This is very routine stuff that is common to inject and use in any compromised machine.
For example I help a friend try to clean up a Windows XP machine.
In this particular case I believe it was a web exploit that caused the attacker to get access to the machine. From that point they installed a rootkit that subverted the NT kernel. From what I read it installed a driver into the kernel using APIs provided for the file systems. It created a secret subvolume in the main C drive that allowed them to install and run whatever they wanted.
Exploit leaded to root kit. The rootkit then would download various payloads that would try to do things like send spam or try to gleam bank passwords and such things.
These 'payloads' would be what would be noticed by the user. Their google searches would get all screwed up. Or the anti-virus would notice changes to the system binaries and such things. You'd run the ant-adware or anti-virus utilities that various websites would recommend you to use to remove this or that troublesome software and that would work.. but you'd never hit the rootkit.
Then some days later the rootkit would just download and install some other malware.
So people's machines would seem like they would get compromised over and over again, but it really only needed to happen once.
> Perhaps the intruders were not very good at their job.
Perhaps the intruders didn't give a crap if you detected them or not.
Or perhaps they thought the administrator was incompetent enough enough that they wouldn't notice and that when you did notice they changed their approach to something more secretive.
Really the only appropriate action, unless you are seeking to press charges or something like that, would be to wipe the server and restore it from a known good backup. Anything else is a disservice to yourself or the people you are trying to help. Cleaning up manually may help or may not. It's really impossible to be sure.
Cleaning up a compromise Posted Feb 21, 2013 17:32 UTC (Thu) by man_ls (subscriber, #15091) [Link] You have a point, of course. But it largely depends on the context. An absolute like "there is no way to know you succeeded so better wipe the whole machine" can be true if you are working for the NSA. In this particular case the crackers just wanted to send their bloody spam from the server; they were not interested in anything else. In fact we were getting lots of abuse reports, which stopped after the cleanup. It is possible that the spammers still had another backdoor into the system (besides the compromised SSH binary), but why would they enter the machine and not send any more spam? In this case the proof is in the pudding.Rootkit detectors are supposed to work well, at least in Linux. It is an arms race between them and rootkit developers, but in this case my money is definitely on the good guys. On Windows it is probably harder to be thorough. On my personal desktop machine I would be much more paranoid. On this particular web server wiping it out was more trouble than doing a cleanup, and by the way the customer wanted it this way. Perhaps a poor excuse, but good enough for me in this situation. So I am not going to advice anyone else to clean up a compromised machine, just to consider carefully your options.
Secure boot Posted Feb 22, 2013 13:30 UTC (Fri) by ekj (guest, #1524) [Link]
You can boot to a known-good rescue-system from a usb-stick or cd-rom or whatever, and use the tools there to scan your system.
Ofcourse this is only good if you trust your bios to actually load what you tell it to load, but that's true with secure boot too: if you don't trust your bios to load what you tell it to, then there's little reason to trust the same bios to correctly implement secure boot.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 13:24 UTC (Mon) by Trelane (subscriber, #56877) [Link]
Doesn't doing this also remove the ability to verify firmware?
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 13:43 UTC (Mon) by mirabilos (subscriber, #84359) [Link]
I’d rather urge people to not buy a Restricted Boot platform at all. Or EFI, for that matter…
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 19:59 UTC (Mon) by hummassa (subscriber, #307) [Link]
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.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 18, 2013 20:27 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> 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 (subscriber, #307) [Link]
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]
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 (subscriber, #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]
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 (subscriber, #31333) [Link]
> 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]
> 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 (guest, #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,
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] 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]
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 (subscriber, #25256) [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 - 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] 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]
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]
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]
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]
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]
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]
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 (guest, #4433) [Link]
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,
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]
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]
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 (subscriber, #2285) [Link]
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]
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 (subscriber, #2285) [Link]
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]
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 (subscriber, #2285) [Link]
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] 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 (subscriber, #2285) [Link]
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 (subscriber, #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] 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 (guest, #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,
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 22, 2013 17:28 UTC (Fri) by etienne (subscriber, #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.
Bottomley: Owning your Windows 8 UEFI Platform Posted Feb 20, 2013 15:49 UTC (Wed) by dougg (subscriber, #1894) [Link]
Has anybody succeeded in building this on Ubuntu (12.10) or Debian (7.0) X86_64 platforms? After several hours I have concluded this is a complete mess with incompatibilities between the gnu-efi packages available on Ubuntu, Debian and the rpm world (the former don't have uefi_call_wrapper). This is not ready for prime time.
|
|||||||||||||