On Wed, 2017-11-22 at 12:06 +0100, Ansgar Burchardt wrote: > Hi, > > I have some questions about UEFI-Secure Boot; some are very general > questions how this works and what it provides, some are about the > proposed implementation (like how long signing takes). > > I'm trying to understand what the requirements are and what we are > trying to provide to be able to come up with a solution that also > works well for ftp-master. > > What do we want? > ---------------- > > Is this just about being able to boot on hardware that has UEFI-Secure > Boot with Microsoft keys enabled by default? Or are there any further > benefits? I believe there is some interest from HP in supporting Secure Boot on arm64 systems that would not have a Microsoft key enabled. Potentially there would also be UEFI systems where the key store has been configured to trust Debian and not MS. > What are the minimal requirements? > ---------------------------------- > > What is the minimal effort? As far as I understand Microsoft will sign > shim; shim will boot stuff signed by Debian's key (grub, kernel); grub > is allowed to boot a signed kernel and unsigned kernels if > ExitBootServices() is called before control is handed over. I don't think we will have the exception for unsigned kernels. My understanding is that the exception is compliant with the UEFI Secure Boot requirements but may not meet the MS signing requirements. > So the minimal effort is to just have grub signed by Debian? Or could > even shim call ExitBootServices and just continue loading grub like on > systems without UEFI-Secure Boot enabled? > > It was mentioned that the kernel might want to run quirks before calling > ExitBootServices (and so the kernel has to be signed). Can these run > before modules are loaded? Or are they included in modules? What > happens if they are not run (as for an unsigned kernel)? > > Can the kernel apply the quirks when UEFI-Secure Boot is not enabled? I don't know what quirks these might be. The only quirks I can see in the kernel's EFI stub don't look like they would be needed if the kernel is booted the old way. > In the default configuration (where anything MS signed will be booted), > nothing stops an attacker from replacing shim + grub2 with a version > booting an unsigned kernel. So there is no security benefit in having > the kernel signed? In the short run, no. In the long run, Ubuntu's insecure grub builds should be blacklisted. > How many packages are we talking about? > --------------------------------------- > > So far I think shim, grub2, linux, in signed and unsigned versions were > mentioned. Or do more packages provide binaries that need signatures? Also fwupdate, apparently. > What architectures are we talking about? > ---------------------------------------- > > Just amd64? But doesn't arm* have UEFI-Secure Boot too (but MS will not > sign stuff with their arm key or so)? The "lockdown" patch series supports x86 and arm64 currently. > How long does signing take? > --------------------------- > > Using a YubiKey as proposed, how long does signing all binaries take for > the different packages? I think the answer is "way too long", but Julien can be more precise. I proposed to use a file-based key for signing modules. It is easy > What happens when UEFI-Secure Boot can be bypassed? > --------------------------------------------------- > > The requirements from Microsoft state that no unauthenticated code must > be executed before ExitBootServices is called and may revoke submissions > that allow this to happen. > > What happens when root can get the Linux kernel or grub to do so (for > example by exploiting a bug)? Might Microsoft revoke the shim > signature? In theory, yes. > Who can upload files to be signed? > ---------------------------------- > > It was proposed that not all DDs should be able to upload binaries that > will be signed. Why? > > Who can update shim? > -------------------- > > Who can update shim(-signed)? > > src:shim-signed includes pre-built binary > ----------------------------------------- > > src:shim-signed contains a binary without source (the source is in > shim). Could it only contain the detached signature (sbattach --detach) > in the source package and combine it with the binary from shim at build > time? Plus a hash to make sure the result is what it should be. [...] Yes, this is obviously the correct way to do it. It is how src:linux-signed worked when it was in Debian. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson
Attachment:
signature.asc
Description: This is a digitally signed message part