Re: shim-signed

[Steve McIntyre <steve@einval.com>]

The Wanderer wrote:
>On 2022-04-26 at 10:14, Marc Haber wrote:
>
>> On Sat, 23 Apr 2022 18:21:47 +0100, Steve McIntyre
>> <steve@einval.com> wrote:
>
>>> Alternatively, people can build replacement shim-signed packages
>>> using their own root of trust if desired. If we had a large enough
>>> number of users wanting a different root of trust, we could even
>>> offer our own different shim-signed package to match.
>> 
>> I would probably prefer to have grub an/or the kernel signed,
>> avoiding additional code, but maybe having some explanation would
>> convince me that the shim actually improves things additionally to
>> adding complexity.
>
>My understanding has always been that the point of having a
>Microsoft-signed shim, rather than having Microsoft sign GRUB or the
>kernel, is to A: avoid the need for round-trip with Microsoft's signing
>facilities every time the GRUB or kernel packages are updated, and B:
>ensure that end-users can still build their own kernels (et cetera)
>without having to go through the Microsoft signing process, even if
>their systems are set up to take advantage of the signed shim.

Correct on both counts. There's also:

  C: Microsoft will not sign GPL software here

Shim is deliberately licenced permissively to get around that issue.

>(And the point of having Microsoft sign it, rather than using a signing
>key under the control of e.g. Debian, is that Microsoft's key is already
>considered valid by the relevant firmware environments - including the
>ones that can't be told to add another key to the list of valid ones.
>That avoids having another barrier to entry, in the form of a set of
>steps at the start of the install process which is going to be different
>per UEFI designer, and is also going to be complex and unintuitive from
>the perspective of a non-technical potential new user.)

Nod. As we found in the Arm ecosystem a few years ago when discussing
a similar setup for SB, it's also *very* difficult to find people who
are capable, willing, large and trusted enough to act as the CA. Linux
users may not like it that Microsoft are involved here, but system
vendors also care here. There's potentially a huge liability for
broken systems if somebody screws up...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews