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

Peter Jones pjones at redhat.com
Mon May 24 16:09:36 BST 2021


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.

-- pjones




More information about the Efi mailing list