[Discuss] Disabling UEFI and dual booting Linux and Windows

[tmetro+blu at gmail.com (Tom Metro)]

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/