* [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).