* [PATCH] SUPPORT.md: add Dom0less as Supported
@ 2021-07-14 0:39 Stefano Stabellini
2021-07-14 18:01 ` Julien Grall
0 siblings, 1 reply; 5+ messages in thread
From: Stefano Stabellini @ 2021-07-14 0:39 UTC (permalink / raw)
To: xen-devel
Cc: sstabellini, julien, andrew.cooper3, george.dunlap, jbeulich, iwj, wl
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
+
# Format and definitions
This file contains prose, and machine-readable fragments.
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] SUPPORT.md: add Dom0less as Supported
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
0 siblings, 1 reply; 5+ messages in thread
From: Julien Grall @ 2021-07-14 18:01 UTC (permalink / raw)
To: Stefano Stabellini, xen-devel
Cc: andrew.cooper3, george.dunlap, jbeulich, iwj, wl
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 we want to exclude this combination or mention
that XSAs will not be issued if the domU can read secret from unscrubbed
memory?
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SUPPORT.md: add Dom0less as Supported
2021-07-14 18:01 ` Julien Grall
@ 2021-07-14 19:28 ` Stefano Stabellini
2021-07-14 19:43 ` Julien Grall
0 siblings, 1 reply; 5+ messages in thread
From: Stefano Stabellini @ 2021-07-14 19:28 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, xen-devel, andrew.cooper3, george.dunlap,
jbeulich, iwj, wl
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? I thought the XSA-372 patches take
care of the problem?
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SUPPORT.md: add Dom0less as Supported
2021-07-14 19:28 ` Stefano Stabellini
@ 2021-07-14 19:43 ` Julien Grall
2021-07-14 23:46 ` Stefano Stabellini
0 siblings, 1 reply; 5+ messages in thread
From: Julien Grall @ 2021-07-14 19:43 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, andrew.cooper3, george.dunlap, jbeulich, iwj, wl
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SUPPORT.md: add Dom0less as Supported
2021-07-14 19:43 ` Julien Grall
@ 2021-07-14 23:46 ` Stefano Stabellini
0 siblings, 0 replies; 5+ messages in thread
From: Stefano Stabellini @ 2021-07-14 23:46 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, xen-devel, andrew.cooper3, george.dunlap,
jbeulich, iwj, wl
On Wed, 14 Jul 2021, Julien Grall wrote:
> 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.
Ah right, I remember what you are talking about. I'll update the patch.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-07-14 23:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2021-07-14 23:46 ` Stefano Stabellini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).