On February 2, 2023 7:17:01 AM PST, James Bottomley <j...@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 >
Somewhat aside... There are other issues with passing the entropy seed in memory, of course; in order to avoid accidental or malicious reuse it would be far better if the entropy was actively pulled at use time via virtual I/O, a hypercall, or RDRAND/RDSEED emulation, but I do realize that that is not always an option.
