Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding

[James Bottomley <jejb@linux.ibm.com>]

On Wed, 2023-02-01 at 16:50 +0000, Peter Maydell wrote:
> On Wed, 1 Feb 2023 at 15:25, James Bottomley <jejb@linux.ibm.com>
> wrote:
> > 
> > On Wed, 2023-02-01 at 10:10 -0500, Jason A. Donenfeld wrote:
> > > This is already fixed via the patch that MST just sent in his
> > > pull.
> > > So wait a few days for that to be merged and it'll be all set.
> > > 
> > > No need for this patch here. Do not merge.
> > 
> > If it's not a secret, would it be too much trouble to point to the
> > branch so we can actually test it?  It does seem that the biggest
> > problem this issue shows is that there wasn't wide enough
> > configuration
> > testing done on the prior commits before they were merged.
> 
> In general you shouldn't expect commits to be visible in
> a git branch before they get merged -- the QEMU process
> is not exactly identical to the kernel one.
> 
> For a particular patch on the mailing list, you can get a git branch
> with it applied by looking for the patch in https://patchew.org/QEMU/
> if that's more convenient than just applying it by hand.

The real issue is there have been so many patches flying around for
this, it's not clear exactly what combination needed to be tested.  Dov
found the branch in tags/for_upstream but it's still failing measured 
direct boot, although the failure has shifted from the hash check of
the kernel to the hash check of the command line.

All I really wanted was a link to the patch ... I don't need the tree
because inspection will tell me that it adds unexpected data at the end
of an integrity checked file.

> We also don't tend to want patches hanging around for testing
> before they get merged[*] -- we figure that "in upstream git"
> is the place that actually gets tested in practice; almost
> nobody will be working with or testing anything else.
> 
> [*] The fix Jason refers to here that's in MST's pullreq
> unfortunately hasn't made it upstream as quickly as I
> would like, due to a combination of things including us
> having to pause CI for a week when we ran out of minutes.

OK, so the problem is still the same as it was before: adding
unexpected data to an integrity checked file.

I don't get why there's all this dancing around trying to find space. 
Surely when the parameter was added, since it was a fixed size, the
kernel header was expanded and the boot protocol version bumped?  So we
can use that to identify kernels which can use this property and have
the space to insert it directly.

James