Re: questions about UEFI-Secure Boot
On Thu, Nov 23, 2017 at 01:00:38PM +0000, Ben Hutchings wrote:
>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.
Nod. There isn't (yet) a central trust root for arm64, so HP have been
shipping systems using their own key so far.
>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.
It's a subject of some controversy, certainly.
>> 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.
Nod. fwupdate will apply firmware updates directly from UEFI at boot,
so will want to be signed.
>> 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.
So at least amd64, i386 and arm64 so far. UEFI is happening on armhf
too, but I'm not aware of any UEFI SB efforts happening there, in the
Linux world at least.
>> 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
incomplete sentence?
>> 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.
Bugs happen. If Microsoft have revoked any keys so far, they've been
quiet about it. But there is support for revocation of keys, both
directly at the UEFI level and in mok/shim.
>> 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?
I don't think I've seen that seriously proposed anywhere...?
>> Who can update shim?
>> --------------------
>>
>> Who can update shim(-signed)?
In theory, anyone. In practice, only a small number of people have
access to the key material needed to ask for a new signature for a new
shim binary. Tollef was setting up (has set up?) m-of-n sharding for
that key material.
>> 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.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
Reply to: