[RFC] Skip boot memory scrub on platforms with full-memory encryption

["Samuel.Montgomery61" <Samuel.Montgomery61@xxxxxxxxxxxxxx>]

Hello,

Xen's boot-time memory scrub is one of the more time-consuming steps
during boot, particularly on systems with large amounts of RAM. I'd
like to propose skipping it on systems with hardware full-memory
encryption (e.g., Intel TME, AMD TSME).

These features encrypt all DRAM transparently using an ephemeral key
generated by the CPU at each boot. The key is not accessible to
software and does not persist across reboots. This means residual data
from any previous session where encryption was active is unreadable --
the same property that boot scrubbing exists to provide.

The important nuance is that Xen needs to confirm encryption has been
continuously active since the last scrub, not just that it is active
now. If encryption was only recently enabled in firmware, residual
plaintext from prior unencrypted sessions could still be present in
pages that were never overwritten. Possible approaches:

  - Record "encryption active" to an EFI variable each boot; skip the
    scrub only if the flag is present from the previous boot.
  - Expose a command-line option for administrators to assert that
    encryption has been consistently enabled.
  - Some combination of the two.

The optimization would apply only to the cross-reboot case. Runtime
scrubbing when domains shut down would be unaffected, since all domains
share the same key during a running session.

Edge cases worth considering:

  - Memory written by firmware before encryption activation.
  - Crash/kexec without a full hardware reset (key may not change).
  - Suspend/resume (some implementations restore the prior key).
  - Interaction with existing bootscrub= command-line options.

As a broader note, multi-key extensions to full-memory encryption (such
as those used by AMD SEV and Intel TME-MK) could eventually eliminate
the need for runtime scrubbing as well, by giving each domain its own
key. This is relevant to the confidential computing work currently
underway (Teddy Astie's recent AMD SEV RFC), though the boot-scrub
optimization proposed here is independent and much simpler.

Feedback welcome on whether the reasoning is sound and whether there
are edge cases I've missed.

Thanks,

Sam

ps. I'm not subscribed to the list, so please CC me in replies.