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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 04/05/2026 5:18 pm, Samuel.Montgomery61 wrote:
> On 04.05.2026 XX:XX, Jan Beulich wrote:
>> 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?
>  
> A skilled admin could certainly use bootscrub=off today. But I come at
> this from the Qubes OS project, where most users expect the system to
> work out of the box. Your average Qubes user won't know how or when to
> pass a Xen command line option. Having Xen detect encryption and do the
> right thing automatically would substantially benefit the project.
>  
> I also forgot to mention in my previous email that there's a broader
> opportunity with multi-key encryption (SEV, TME-MK). In this case, Xen
> could skip runtime scrubbing as well, since a domain's pages become
> unreadable the moment its key is destroyed. That's a separate feature,
> but I think it makes the case for Xen understanding and acting on the
> encryption capabilities of the platform rather than leaving it to users
> to set the right combination of options.
>  
> I believe the edge cases actually support the case for automatic
> configuration, since any user manually disabling the scrub would need
> to reason about kexec without a full hardware reset, suspend/resume
> restoring the previous key, and firmware writing to memory before
> encryption is activated, at very least. Auto-detection could handle
> these transparently rather than leaving them to the user.

What exists in Xen right now is a mess.

Scrubbing is ill-defined.  One part of it says "make sure after a crash
we don't have old guest data around in memory", and encryption is
specifically irrelevant for this case; the ephemeral key doesn't change
on warm reset.

Something relevant to QubeOS is that for DRTM (Anti Evil Maid), it is
required (by the TXT spec at least) that Xen scrub memory between
receiving a shutdown request and actioning it.  Failure to do so causes
firmware to zero everything on the way back up.  Fixing this is an open
TODO.

Another aspect is to populate Xen's free memory pool with ready-to-go
memory.  Here we have a weird split, because when scrubbing in Xen's
idle loop as introduced, the boot time scrub was not disabled.  Except
that doing this in the idle loop during boot is bad because it
interferes with microcode loading during AP boot, which is why it's
delayed until the machine is mostly up.

There probably is room to tweak a little, but "RAM being encrypted" has
no baring on the other safety justifications.

~Andrew