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

[H. Peter Anvin]

On February 2, 2023 7:17:01 AM PST, James Bottomley <jejb@linux.ibm.com> wrote:
>On Thu, 2023-02-02 at 07:03 -0800, H. Peter Anvin wrote:
>[...]
>> NAK. We need to fix the actual problem of the kernel stomping on
>> memory it shouldn't, not paper around it.
>
>This is a first boot situation, not kexec (I just updated kexec because
>it should use any new mechanism we propose).  Unlike kexec, for first
>boot we're very constrained by the amount of extra space QEMU has to do
>this.  The boot_params are the first page of the kernel load, but the
>kernel proper begins directly after it, so we can't expand it.  The two
>schemes tried: loading after the kernel and loading after the command
>line both tamper with integrity protected files, so we shouldn't use
>this mechanism.  This is the essence of the problem: If we add this
>area at boot, it has to go in an existing memory location; we can't
>steal random guest areas.  All current config parameters are passed
>through as fw_config files, so we can only use that mechanism *if* we
>know where the area ends up in the loaded kernel *and* the file isn't
>integrity protected (this latter is expanding over time).
>
>If we could wind back time, I'd have added the 32 byte random seed to
>boot_params properly not coded it as a setup_data addition, but now
>we're stuck with coping with existing behaviour, which is why I thought
>the retro fit to boot_params would be the better path forward, but if
>you have any alternatives, I'm sure we could look at them.
>
>James
>

One option that you do have that should be backwards compatible, even, is to 
mark that memory as reserved in the memory map, basically doing the job that 
the kernel decompressor should have done in the first place. The downside is 
that existing kennels will never reclaim that memory, but since it is such a 
small amount, it shouldn't really matter.

We could even reserve a memory type code for it; that way a newer kernel could 
know to reclaim that memory at the very end of the boot process, when it would 
deallocate other setup_data entries. Existing kernels will, for obvious 
reasons, treat unknown memory types as equivalent to type 2 – permanent keep 
out.