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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.05.2026 05:24, Samuel.Montgomery61 wrote:
> 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.

As you point out, there are issues with default-disabling. We already
have the "bootscrub=" command line option. Is there a reason this can't
be used here as well? I.e. is there a strong reason to put in (perhaps
significant) effort to identify and cover all the corner cases
associated with default-disabling?

Jan

>   - 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.
>