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

[Julian Andres Klode]

On Mon, May 24, 2021 at 11:51:02AM -0400, Peter Jones wrote:
> > > > 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.
> >
> > Wondering if we should just have a VendorDbx field instead of merging
> > it in the table. That would also avoid the refactoring altogether -
> > well, so would removing mirroring ;).
> 
> I really don't like adding more variables with the same meaning that
> kernel and userland tooling have to check. The ideal number of "db"
> variables and "dbx" variables from that point of view are both one.
> We're already at two for each, and every new variable we add to
> express the same thing is another point of failure in every consumer.
> Unless we have a good sense of why separate lists would be meaningful
> to the code consuming it, it's hard for me to see justification for
> not providing that code with a unified list.  If there are good use
> cases for that, I could probably be convinced.
> 

In case of Ubuntu or other large vendor dbx, one thing it is useful
for is for making mokutil --list-enrolled --mokx readable. It's a mess
right now with the 19 KB of hashes of binaries being revoked :) OTOH,
it becomes inconsistent with normal --list-enrolled :/

shim special cases vendor dbx and says stuff is blocked because
it's in vendor dbx, so giving downstreams a merged view kind of
takes away their ability to do the same. It could be useful to
know why a binary is blocked - whether it was firmware, shim,
or yourself (same for allowed, but probably to a lesser extend).

But yeah, I'm mostly trying to avoid refactoring and constructing my
arguments around that ;)

An argument against it would be if there's code out there using
the table already. But I don't know that, certainly the kernel uses
neither variables nor table, but I heard xnox is playing with that.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en