disabling MokListXRT vendor dbx addendum (Was: Re: Report of (additional) boot regression on MacBookPro14,3 with 15.4)

[Dimitri John Ledkov]

On Mon, May 24, 2021 at 9:14 PM Peter Jones <pjones at redhat.com> wrote:
>
> On Mon, May 24, 2021 at 9:53 AM Julian Andres Klode
> <julian.klode at canonical.com> wrote:
> > We believe that this, and several other issues we are seeing, are caused
> > by our vendor dbx being 19 KB large.
> >
> > As such, we'd like to ship the attached patch to disable adding the
> > vendor dbx to MokListX when it is being mirrored to MokListXRT.
> >
> > We do not believe that this is a security issue: The MokListXRT variable
> > is not used by our released kernels yet, and we can just bake the vendor
> > dbx into future kernels that do read MokListXRT and avoid passing it
> > through the limited storage space.
>
> I'm not strongly against this, but what I'd /rather/ see is a flag
> added to say to only add the "addend" to our config table, not to the
> variable.
>
> > This should unblock MacBooks and the older ThinkPads which ran out of
> > storage space while trying to mirror the var :)
> >
> > On a related note, we are also considering to disable mirroring entirely
> > when not booting securely, so we don't even try to write vars on
> > those MacBooks and X220 ThinkPads and such.
>
> There is value in mirroring even when not enforcing, though not so
> much when SB is unsupported—it helps with the ability to understand
> what would happen on a given machine if SB were enabled.  For the
> longer term we need to be moving towards an Audit Mode+IEIT model when
> not enforcing.  That said, again I'd be pretty happy with a solution
> that just uses the config table and not the variables.  We've
> demonstrated clearly that the variables simply do not work for any
> non-trivial use case here; we can do "best effort" with the variables
> for compatibility with older userland mokutil and kexec, but that's
> all we're going to accomplish.
>
> The config table has to be the mandatory part going forward, and we
> need to be looking at phasing out the use of variables anyway. So I
> would encourage you to look at making that work correctly and only
> nerfing the variables.
>

Reading MokListsXRT was merged into v5.13 kernel, but only from efivars.

I have submitted a patch to read MokListsXRT from the mokvar table
too, but there are no comments from maintainers about it so far.
See https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.ledkov@canonical.com/

It will be applied in the Ubuntu kernels soon.

In Debian, they are shipping their own patch to the same effect for a
while now see https://sources.debian.org/src/linux/5.10.28-1/debian/patches/features/all/db-mok-keyring/0002-MODSIGN-load-blacklist-from-MOKx.patch/?hl=112#L112

It would be nice if reading MokListXRT from the mokvar table made it
into the upstream kernel, cause I don't think any other distros read
MokListsXRT at all yet, and if they will start doing so, they will not
do it via the mokvar interface.

Could you please comment on my upstream patch? Or if you prefer I
could attempt to upstream Debian's patch instead.

-- 
Regards,

Dimitri.