All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com,
	george.dunlap@citrix.com, jbeulich@suse.com, iwj@xenproject.org,
	wl@xen.org
Subject: Re: [PATCH] SUPPORT.md: add Dom0less as Supported
Date: Wed, 14 Jul 2021 20:43:08 +0100	[thread overview]
Message-ID: <f443ca4f-a942-7765-a8c0-072d2844a0d9@xen.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2107141224550.23286@sstabellini-ThinkPad-T480s>

Hi Stefano,

On 14/07/2021 20:28, Stefano Stabellini wrote:
> On Wed, 14 Jul 2021, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 14/07/2021 01:39, Stefano Stabellini wrote:
>>> Add Dom0less to SUPPORT.md to clarify its support status. The feature is
>>> mature enough and small enough to make it security supported.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
>>>
>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>> index 317392d8f3..c777f3da72 100644
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -832,6 +832,12 @@ OVMF firmware implements the UEFI boot protocol.
>>>          Status, qemu-xen: Supported
>>>    +## Dom0less
>>> +
>>> +Guest creation from the hypervisor at boot without Dom0 intervention.
>>> +
>>> +    Status, ARM: Supported
>>> +
>>
>> After XSA-372, we will not scrubbed memory assigned to dom0less DomU when
>> bootscrub=on.
> 
> Do you mean *before* XSA-372, right?

No, I really meant *after* XSA-372.

> I thought the XSA-372 patches take
> care of the problem?

It didn't. We have an open question for the bootscrub=on one. From the 
commit message of patch #1:

         2) The memory allocated for a domU will not be scrubbed anymore 
when an
         admin select bootscrub=on. This is not something we advertised, 
but if
         this is a concern we can introduce either force scrub for all 
domUs or
         a per-domain flag in the DT. The behavior for bootscrub=off and
         bootscrub=idle (default) has not changed.

>  >
>> Do we want to exclude this combination or mention that XSAs will
>> not be issued if the domU can read secret from unscrubbed memory?
> 
> I could say that if bootscrub=off then we won't issue XSAs for domUs reading
> secrets from unscrubbed memory. But it is kind of obvious anyway? I am
> happy to add it if you think it is good to clarify.

Right, it is pretty clear that bootscrub=off will not scrub the memory 
and the "problem" would not be specific to dom0less.

The one I asked to clarify is bootscrub=on because one may think the 
memory is scrubbed for dom0less domU for all the cases but bootscrub=off.

IIRC when we discussed about it on security@xen.org, we suggested that 
it would be fine to rely on the bootloader to scrub it. But I think this 
needs to be written down rather waiting for it to be re-discovered.

The other solution is to fix it properly.

Cheers,

-- 
Julien Grall


  reply	other threads:[~2021-07-14 19:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14  0:39 [PATCH] SUPPORT.md: add Dom0less as Supported Stefano Stabellini
2021-07-14 18:01 ` Julien Grall
2021-07-14 19:28   ` Stefano Stabellini
2021-07-14 19:43     ` Julien Grall [this message]
2021-07-14 23:46       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f443ca4f-a942-7765-a8c0-072d2844a0d9@xen.org \
    --to=julien@xen.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.