On Mon, 26 Sept 2022 at 17:53, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > On both x86 and dtb-based archs, the seed in memory is zeroed out by the > kernel after reading. So, as far as the guest is concerned, there's > forward secrecy. Except! Except if the guest has someway of > re-requesting that seed from the host. This patch prevents that from > happening through fw_cfg on x86. Somebody told me last week that device > tree archs don't use fw_cfg, so this won't be a problem there. I haven't > yet looked to verify that yet, though, or looked if there are other > mechanisms.
I am leaping in here with no context, so I may well have the wrong end of the stick, but: "does this system have a fw_cfg device" and "does this system pass a device tree to the kernel" are orthogonal questions: fw_cfg, no device tree: classic x86 pc; arm virt board when booting UEFI firmware in the guest fw_cfg, device tree: arm virt board booting a kernel directly no fw_cfg, device tree: arm vexpress-a15 board (or any other just-emulating-hardware machine type) no fw_cfg, no device tree: arm sbsa-ref board (and probably lots of non-arm architecture machines too) PS: if we're going to give FW_CFG_KERNEL_DATA magic side effect behaviour, is there somewhere we can document that magic? thanks -- PMM
