LWN: Comments on "An update on UEFI secure boot" https://lwn.net/Articles/464394/ This is a special feed containing comments posted to the individual LWN article titled "An update on UEFI secure boot". en-us Sat, 11 Oct 2025 15:07:19 +0000 Sat, 11 Oct 2025 15:07:19 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net An update on UEFI secure boot https://lwn.net/Articles/468493/ https://lwn.net/Articles/468493/ mjg59 <div class="FormattedComment"> Given the way UEFI works, it'd be trivial for you to extract the decryption key in any such scenario.<br> </div> Sun, 20 Nov 2011 21:11:03 +0000 An update on UEFI secure boot https://lwn.net/Articles/468484/ https://lwn.net/Articles/468484/ oak <div class="FormattedComment"> That's where DRM comes in. The content is crypted so that only your firmware which has the correct keys can decrypt it. Firmware will do that only if boot was secured. "Content" can be anything; challenge from your internet bank, video stream, code loaded on game startup etc.<br> <p> <p> <p> </div> Sun, 20 Nov 2011 20:51:58 +0000 An update on UEFI secure boot https://lwn.net/Articles/466067/ https://lwn.net/Articles/466067/ mjg59 <div class="FormattedComment"> That's something it allows, yes. But it also allows you to assume that nothing has modified system state before you start the kernel, which means that if the first piece of userspace you start is a virus checker you know that the answers it gets from the kernel can be trusted.<br> </div> Mon, 07 Nov 2011 00:23:13 +0000 An update on UEFI secure boot https://lwn.net/Articles/466053/ https://lwn.net/Articles/466053/ njs <div class="FormattedComment"> Good idea. I haven't seen that in any MS literature, but I haven't looked at much either. Though, "reliably" is probably the wrong word -- you could prevent a rootkit from infecting the backup partition, but it could easily trash the backup partition so that you still had to use a traditional reinstall method.<br> </div> Sun, 06 Nov 2011 22:48:05 +0000 An update on UEFI secure boot https://lwn.net/Articles/466050/ https://lwn.net/Articles/466050/ foom <div class="FormattedComment"> I was thinking it was so that a "reinstall windows" button could reliably reinstall windows from the HD, without the possibility of any rootkits getting in the way.<br> </div> Sun, 06 Nov 2011 22:40:53 +0000 An update on UEFI secure boot https://lwn.net/Articles/465460/ https://lwn.net/Articles/465460/ njs <div class="FormattedComment"> As I understand it, the sole point of "secure boot" is to let you run your *virus checker* at boot time, in such a way that your virus checker can't be disabled by malware.<br> <p> If you don't have a securely signed virus-checker that you run directly from your boot-loader, then all this secure boot stuff is useless, AFAICT.<br> <p> </div> Thu, 03 Nov 2011 06:41:13 +0000 An update on UEFI secure boot https://lwn.net/Articles/465434/ https://lwn.net/Articles/465434/ slashdot <div class="FormattedComment"> But... does this really enhance security that much in the real world?<br> <p> Because the thing is that an unprivileged process running in Windows already cannot replace the Windows OS image with something else due to OS permissions (just like a non-root Linux user cannot just replace the kernel if the administrator did a sensible job).<br> <p> And if a trojan can bypass OS permission check, then it can set itself to automatically run on boot and re-escalate every time.<br> <p> Even if support for any form of autorun is dropped, it would still be possible to just infect a non-Microsoft-signed executable which the user runs very often (for instance Firefox or a game).<br> <p> <p> The only benefit I see is that installing a patch for an OS bug will be more likely to disable malware exploiting it, and while it is possible for malware to block the OS update (and make it look it was applied), this requires substantial additional work on the part of the malware author.<br> <p> <p> BTW, this assumes that Windows 8 will refuse to load any unsigned drivers, system executables, DLLs, as well as any configuration/script file capable of loading binary code, as otherwise it's totally pointless, since you just infect those instead of the UEFI image.<br> I have a feeling however that they will fail to actually enforce this properly.<br> <p> </div> Thu, 03 Nov 2011 04:23:08 +0000 An update on UEFI secure boot https://lwn.net/Articles/464775/ https://lwn.net/Articles/464775/ giraffedata <blockquote> The bootloader can tell the OS [that it was correctly signed] etc. But the bootloader can lie to you in "secure boot": </blockquote> <p> Not quite. The bootloader <em>can't</em> tell the OS that it was correctly signed and the OS can't ask. Implementing that function would be ridiculous, since the bootloader could lie. It would be like a prostitute asking a potential client if he is a cop. <p> <em>That's</em> the difference between secure boot and trusted computing. With trusted computing, the program can determine it is running on a platform the program trusts; with secure boot, the user can ensure everything running on his computer is something <em>he</em> trusts. Thu, 27 Oct 2011 23:50:19 +0000 Tablets https://lwn.net/Articles/464748/ https://lwn.net/Articles/464748/ jmorris42 <div class="FormattedComment"> No they won't lock us out of PCs and servers.... now.<br> <p> But finding a phone with an open boot loader is a challenge today. Finding one that boots in a well described way amendable to replacing the OS is all but impossible. Same for tablets.<br> <p> This tablets are where the smart people have decided all development is headed, see GNOME3 and Microsoft's Metro UI in Win8. Once they get people to accept tablets as sealed devices that get replaced instead of upgraded the desktop will accept the new reality. Or at least I'd bet that is the plan.<br> <p> Up to now they have only been toying with us, because they aren't really trying too hard and because they are still learning themselves. So most popular devices get jailbroken eventually, even the mighty PlayStation 3 fell to the hackers. But give it a few more generations and let more and more functions get integrated into a single die and they will perfect locks that won't get broken before the product is obsolete. And they all dream of that day, if for different reasons some of which are are sometimes at cross purposes.<br> <p> Microsoft dreams of zero piracy and zero competition. Hollywood dreams of charging for every view of their precious content. Government wants the 100% reliable snooping with no opt out and the ability to mandate... mostly because mandating is what the government DOES. The bankers dream of microtransactions for everything... all perfectly secure to ensure they get their taste. With a secure computing environment everyone wins... except the nominal owner of the machine. Of course even that idea is old, now you just get to use it because selling things instead of making you a continuing revenue stream is just so 20th Century.<br> </div> Thu, 27 Oct 2011 18:43:44 +0000 An update on UEFI secure boot https://lwn.net/Articles/464723/ https://lwn.net/Articles/464723/ Aliasundercover <div class="FormattedComment"> There is an old saying -- Never attribute to malice that which is adequately explained by stupidity.<br> <p> Never is a strong word, I say instead one should be slow to attribute to malice ...<br> <p> Microsoft has long ago climbed this hill. They never just want to be paid for their products, everything is strategic, everything has an exclusionary angle. This is one of their more dangerous ploys. <br> <p> </div> Thu, 27 Oct 2011 16:30:15 +0000 An update on UEFI secure boot https://lwn.net/Articles/464714/ https://lwn.net/Articles/464714/ raven667 <blockquote>The issue is not if you will end up buying machines where you can't boot Linux because secure boot can't be switched off. That will not happen, among other things, due to anti-trust issues.</blockquote> <p>I think that is a real concern, not because of any malice on MS or the hardware vendors part but just due to apathy about non-MS desktop systems. It would be easy to load the MS keys into the hardware, flip on the secure-boot feature and not bother to make a UI for loading your own keys or turning the feature off, locking the hardware to only run Win8 (and possibly some OEM version of Win7 that's signed). That's not saying there wouldn't be vendors who do allow key modification or even cater to the Linux market but there was a real danger of the PC market getting locked up in the name of security and turning people into criminals who have to jail-break their machines. Thu, 27 Oct 2011 15:36:19 +0000 An update on UEFI secure boot https://lwn.net/Articles/464713/ https://lwn.net/Articles/464713/ raven667 <div class="FormattedComment"> That's true but we have to be careful that the secure boot infrastructure isn't mis-used, through incompetence or apathy, such that we have to resort to jail-breaking and other potentially illegal activity just to run our own software. This whole discussion started because a naive implementation of the MS Win8 Logo requirements could leave competitive systems on the Desktop out in the cold and MS isn't overflowing with concern about what happens outside their ecosystem.<br> </div> Thu, 27 Oct 2011 15:28:18 +0000 An update on UEFI secure boot https://lwn.net/Articles/464711/ https://lwn.net/Articles/464711/ mjg59 <div class="FormattedComment"> The security comes from the requirement that the user enter the BIOS to disable the feature. If the firmware is implemented in such a way that you can modify this from the OS then it's obviously circumventable, but the design is intended to be such that this is impossible.<br> </div> Thu, 27 Oct 2011 15:15:28 +0000 An update on UEFI secure boot https://lwn.net/Articles/464708/ https://lwn.net/Articles/464708/ simlo <div class="FormattedComment"> Let me see if I understand it correctly:<br> <p> We have a boot chain:<br> <p> firmware -&gt; bootloader -&gt; OS -&gt; applications -&gt; server<br> <p> Each have some build in certificates to verify from left to right: The firmware have a certificate for the bootloader, the bootloader have certificate(s) for the kernel etc. In secure boot, if the signature doesn't match, stop the boot process.<br> <p> To have "trusted computing" you also need to be able to verify from right to left: The server shall be able to be able to see that the application is correctly signed. <br> <p> So to interpret the difference between secure boot and trusted computing:<br> The firmware can tell the bootloader that it was correctly signed. The bootloaded can tell the OS etc. But the bootloaded can lie to you in "secure boot": Secure boot might actually have been turned off in the firmware, but the bootloader have also been changed to lie to the OS that it was correctly signed.<br> Or the user can tell the server that the stack is correctly signed, because there is no way the server can verify it.<br> <p> If that is the case, where is the security? It should be "simple" to either manipulate the firmware to switch off secure boot on specific systems, or trick the user into doing so, while flipping the bits in the bootloader, OS etc. It is harder to install malware on such a system, but far from impossible if you know which bits to flip - and hackers do. The only real things which makes it harder is to figure out how to disable secure boot on many different versions of the firmware. I bet you can manipulate the setting from software, if you know how.<br> <p> <p> </div> Thu, 27 Oct 2011 15:05:12 +0000 An update on UEFI secure boot https://lwn.net/Articles/464706/ https://lwn.net/Articles/464706/ mjg59 <div class="FormattedComment"> Secure boot is not trusted boot. It's impossible for any OS using it to know that it booted via a trusted path.<br> </div> Thu, 27 Oct 2011 14:23:24 +0000 An update on UEFI secure boot https://lwn.net/Articles/464705/ https://lwn.net/Articles/464705/ jzb <div class="FormattedComment"> That could be - but I don't think that's what MSFT is aiming for here. I think they're primarily targeting "greymarket" Windows. But maybe you're right... <br> </div> Thu, 27 Oct 2011 14:20:23 +0000 An update on UEFI secure boot https://lwn.net/Articles/464701/ https://lwn.net/Articles/464701/ simlo <div class="FormattedComment"> I think people are missing the big issue here:<br> <p> The issue is not if you will end up buying machines where you can't boot Linux because secure boot can't be switched off. That will not happen, among other things, due to anti-trust issues.<br> <p> No the problem is that secure boot is the first in the chain against "trusted computing." I.e. to play your media files you have to have booted a trusted OS which only allow trusted software to open your files. Later on your bank will require you to use a trusted OS to do net-banking. Then all kinds of services will require it. Then the ISPs will require it for you to access the internet at all. Then states will require it to make sure you can't access child porn, bomb manuals etc. We all know where that road leads to...<br> <p> <p> </div> Thu, 27 Oct 2011 13:50:21 +0000 An update on UEFI secure boot https://lwn.net/Articles/464684/ https://lwn.net/Articles/464684/ Fowl I don't see how. Running Windows is preferable to Windows not running. I'm just concerned about the ux apocalypse OEMs are going to unleash. Thu, 27 Oct 2011 11:44:27 +0000 An update on UEFI secure boot https://lwn.net/Articles/464680/ https://lwn.net/Articles/464680/ salimma <div class="FormattedComment"> Yet another reminder of why I no longer read any Ziff-Davis publications. Sigh.<br> </div> Thu, 27 Oct 2011 10:58:01 +0000 An update on UEFI secure boot https://lwn.net/Articles/464671/ https://lwn.net/Articles/464671/ dgm <div class="FormattedComment"> <font class="QuotedText">&gt; Secure Boot must is only mandatory to "get the logo" ie. pass Microsoft's tests.</font><br> <p> ... for now. Looks like a wooden horse to me. What will happen when most systems do boot with UEFI secure boot? Probably Windows will start to refuse to run certain applications and open certain files if booted insecure, meaning users will not do that. From there to removing the disable feature is just a little step. Don't you have the feeling of being spoon-fed?<br> </div> Thu, 27 Oct 2011 09:47:48 +0000 An update on UEFI secure boot https://lwn.net/Articles/464664/ https://lwn.net/Articles/464664/ mjg59 <div class="FormattedComment"> Windows 8 logo systems must be UEFI, but Windows 8 will boot fine with BIOS. It's probably worth remembering that there's no real concept of attestation in secure boot, so even if a future version requires both UEFI and the secure boot feature, it'd be easy to fake it up.<br> </div> Thu, 27 Oct 2011 08:41:54 +0000 An update on UEFI secure boot https://lwn.net/Articles/464663/ https://lwn.net/Articles/464663/ Fowl Secure Boot must is only mandatory to "get the logo" ie. pass Microsoft's tests. As Windows 8 will be expected to run on hardware that currently runs Windows 7, it will run without secure boot. I can't see how it couldn't, even intentionally; it's not like bootloaders haven't lied in the past. Thu, 27 Oct 2011 08:39:46 +0000 An update on UEFI secure boot https://lwn.net/Articles/464661/ https://lwn.net/Articles/464661/ petur <div class="FormattedComment"> I don't think being able to switch it on/off in th bios is a usable suggestion, it would make dual boot a nightmare. On the other hand, I do see many dual boot systems switch to VM, but not all. Which raises another question: will Win8 boot in a VM?<br> </div> Thu, 27 Oct 2011 08:17:08 +0000