Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
Rich Pieri wrote: > Tom Metro wrote: >> As opposed to a boot loader that simply lets you chain to any >> arbitrary, unsigned OS loader? > > Yes, but if you're doing that then you should just turn UEFI Secure > Boot off. There's no point to having it enabled if you don't use a > signed second-stage loader and kernel and whatever else. Most of the Linux/UEFI articles from earlier this year advocated exactly such an approach with the purpose that it spares a novice user booting a Live CD from having to delve into BIOS settings. But I had my doubts that Microsoft would permit such a loader to get signed, knowing it could easily be repurposed by malware developers. >> I get how the running shim can present an obvious user prompt to load >> keys, but I'm not following how this shim can guard against its key >> store from being modified by malicious code. > > https://www.suse.com/blogs/uefi-secure-boot-details/ Quoting the page: The enrollment process begins by rebooting the machine and interrupting the boot process (e.g., pressing a key) when the shim loads. The shim will then go into enrollment mode, allowing the user to replace the default SUSE key with keys from a file on the boot partition. If the user chooses to do so, the shim will then calculate a hash of that file and put the result in a "Boot Services Only" variable. This allows the shim to detect any change of the file made outside of Boot Services and thus avoid the tampering with the list of user approved MOKs. An important aspect to remember is that all of this happens during boot time, only verified code is executing now. Therefore, only a user present at the console can say, "I want to use my own set of keys." It can't be malware or a hacker with remote access to the OS because hackers or malware can only change the file, but not the hash stored in the "Boot Services Only" variable. OK, so I'm assuming the "Boot Services Only" variable is stored in some Flash memory managed by the UEFI hardware, and the UEFI system only allows its contents to be altered by code it has validated. If that's the case, then it makes sense. Though there are still details missing. Presumably the "Boot Services Only" variable is accessed via some API (software IRQ?). What is it that makes it accessible only during the boot phase and not later? Does the shim call some API to tell UEFI that the boot phase is over, which locks down access? Also, thanks to MOKs being a list and not just a single MOK, you can make the shim trust keys from several different vendors, allowing dual- and multi-boot from the GRUB2 bootloader. No mention if this could had off to a Windows kernel in a dial-boot setup. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |