[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Samuel.Montgomery61" <Samuel.Montgomery61@xxxxxxxxxxxxxx>
  • Date: Mon, 04 May 2026 16:18:19 +0000
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=protonmail3 header.d=protonmail.com header.i="@protonmail.com" header.h="Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:Feedback-ID"
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 04 May 2026 16:18:36 +0000
  • Feedback-id: 16446063:user:proton
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.