Re: [OT] Secure boot for Super Grub2 Disk plausible?
On Fri, Jan 15, 2016 at 11:14:44PM +0100, adrian15 wrote:
> Hi,
Hi Adrian!
> I am unsure if Super Grub2 Disk it's appropriated for requesting a Secure
>boot signature of it.
>
> I hope this is not too offtopic for you guys.
...
>2. My concerns about Super Grub2 Disk and Secure Boot
>
>2.1. So if I add Secure Boot to Super Grub2 Disk I would like to be able to
>load non-signed kernels.
>
>So I don't if it's possible although I know that Ubuntu guys let you boot
>unsigned Kernels.
>
> If I'm not mistaken the workaround for this limitation that Ubuntu's grub2
>(or maybe the pre-loader) does not let you overwrite some efi memory so that
>you cannot overwrite signatures. (Please correct me on technical details
>because I know I'm not being accurate with the Ubuntu explanation here.)
The Ubuntu signed grub package will load unsigned kernels, but calls
ExitBootServices() first so that kernel does not have access to some
of the UEFI platform underneath. That's still quite a controversial
choice: some people consider it to be mis-guided.
>2.2. As opposed to other pre-loaders that Microsoft has signed the main
>purpose of Super Grub2 Disk is not to boot a signed kernel or operating
>system.
>
>Not sure if the main purpose of a software matters in the Microsoft decision
>making.
Pass - they're remarkably quiet about this.
>2.3. One of the features from Super Grub2 Disk extract entries from cfg files
>when doing its 'Everything' scanning. Not sure if that could be used by some
>malicious virus to place some special cfg files in some specific place. You
>know, so that someone that uses Super Grub2 Disk can bootkit one of their
>OSes.
Hmmm.
>3. Why Secure Boot on Super Grub2 Disk?
>
>So that it works in EFI machines that by default enforce Secure Boot.
>
>4. Super Grub2 Disk and Debian.
>
>This is not specific to my Secure boot concerns but, well, I hope some day to
>integrate Super Grub2 Disk into Debian. Last time I checked Debian I had
>problems with it because:
>
>4.1. Debian packages do not provide a way of building an hybrid (both valid
>in i386-pc and efi machines) iso.
That's been working for a while now, modulo corner cases like buggy
early Intel Macs. I hope you've seen this now!
>4.2. Debian GNU/GRUB Version 2 package version commit was behind what Super
>Grub2 Disk needed for it to work on a Mac-Intel system (The three partition
>types in a single iso hack if you know what I mean).
>
>5. Do you think I would need to sign a pre-loader (like Shim) instead, some
>grub modules or the full ISO ?
There are several signatures in use; the UEFI Secure Boot signature is
normally used on the shim binary, and that shim binary uses a separate
set of embedded keys to verify signatures on further binaries (grub
and/or kernel). At this level, you don't sign the full ISO.
(Obviously, for safety and sanity you'd normally published signed
checksum files to go with your ISO image so that users can verify
downloads, but that's unrelated to UEFI Secure Boot.)
>6. I do not discard having an option so that the user can enforce
>Signed-Booting (I.e. would refuse to boot a non-signed kernel). Do you know
>if it's that even possible in the Ubuntu's grub version?
Pass, sorry - you'd have to ask the Ubuntu folks like Colin Watson or
Steve Langasek.
>So... As a summary what I want to know if what the Ubuntu people did in order
>to be able to boot non-signed kernels would work for me for these two
>purposes:
>
>1) Get the signature approved from Microsoft
>2) Do not lose current Super Grub2 Disk functionality (Boot as many OSes from
>it as you can do right now).
I think you're probably going to need to get your own shim binary
signed, and then it's up to you what further things you'd trust to
load, whether signed or not. This is clearly skating close to the edge
of what Secure Boot is meant to allow.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Reply to: