| Message ID | alpine.DEB.2.21.2107131734170.23286@sstabellini-ThinkPad-T480s (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | SUPPORT.md: add Dom0less as Supported | expand |
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,
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.
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,
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.
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.
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>