To read all comments associated with this story, please click here.
Does this mean that,
if using Windows Signature,
and BIOS activate the network,
then Microsoft could
play with my linux?
I know that UEFI is about identity;
The first in the stack "owns" the stack.
But, could it be that
the BIOS designer,
-the non writable part of the BIOS-
is the real "owner" of the stack?
if using Windows Signature,
and BIOS activate the network,
then Microsoft could
play with my linux?
I know that UEFI is about identity;
The first in the stack "owns" the stack.
But, could it be that
the BIOS designer,
-the non writable part of the BIOS-
is the real "owner" of the stack?
Looks that way.
http://mjg59.dreamwidth.org/11235.html
Also, the reference UEFI implementation most motherboard builders are using is demonstrably buggy and at least as complex as your average OS kernel.
https://www.youtube.com/watch?v=V2aq5M3Q76U
One of the reasons I'll probably be trying to source BIOS-based motherboards for as long as possible and, when that's no longer an option, I'll try to source something known to support reflashing with CoreBoot so I can prune it down to the minimum amount of code needed to boot Linux.
http://www.coreboot.org/
On the plus side, it does mean plenty of room for rooting the UEFI itself which could really put some egg on Microsoft's face.
(I'm sort of hoping that UEFI rootkits make such a mess of things that Microsoft is forced to backpedal on this idiotic "kernel-sized, under-tested, buggy firmware blob" idea)
Brendan,
"I think Fedora are also planning to create a 'shim'. The basic idea is that it's signed with Microsoft's key, and boots other boot loaders."
It's not exactly that simple. Because of the way secure boot was designed (for 3rd party control rather than security), it cannot pass control back to users without compromising security.
Consider that malware could exploit this and install the unrestricted bootloader (signed by microsoft's key) and then install a backdoor through the unrestricted bootloader. This would break secure boot's security on every secure boot desktop in the world and not just your desktop. Now MS would be forced to admit that secure boot is permanently broken, or it would revoke Fedora's key and break legitimate linux installs everywhere.
This is another reason I hate microsoft's secure boot design. Even if they had the best of intentions, it creates a single point of failure. One bug or leak breaks everybody's secure boot security worldwide. It just reaffirms how secure boot has been designed for 3rd party control rather than security.
The shim you referred to can only run locked down versions of linux running signed components. It's probably ok for normal users, but it's not the same free/open linux kernel that we're fond of. We'll become dependent upon Fedora provided kernels, and they'll become dependent upon MS, all so that home users can dual boot a restricted linux on their own machines.
Alfman posted...
Which is exactly why the hacking scene needs to get on breaking this single point of failure as hard and spectacularly as they can, then release something that crashes every system running "secure boot" in such a way to make it clear that it is worse than useless at what it was ostensibly designed to do. Better yet it needs to crash the hardware in such a way the OEMs are liable and it costs them enough pain they instinctively shy away from any future types of such systems. Maybe then it would make the whole thing go away again...
--bornagainpenguin





Member since:
2005-11-16
Hi,
I think Fedora are also planning to create a "shim". The basic idea is that it's signed with Microsoft's key, and boots other boot loaders.
It's possibly not that simple though - I think they're planning to allow end users to add keys to UEFI's store; so that if you try to boot a signed boot loader with the shim, it'll ask if the key should be added. This way Linux can use secure boot too; and all those dual booting Linux users don't have to worry about getting their Linux OS infected by viruses that Windows let in. :-)
- Brendan