> -----Original Message----- > From: Xen-devel [mailto:[email protected]] On Behalf > Of George Dunlap > Sent: 05 November 2018 18:07 > To: [email protected] > Cc: Stefano Stabellini <[email protected]>; Wei Liu > <[email protected]>; Konrad Wilk <[email protected]>; Andrew Cooper > <[email protected]>; Tim (Xen.org) <[email protected]>; George Dunlap > <[email protected]>; Ross Lagerwall <[email protected]>; > Julien Grall <[email protected]>; Jan Beulich <[email protected]>; > Anthony Perard <[email protected]>; Ian Jackson > <[email protected]> > Subject: [Xen-devel] [PATCH v4 2/6] SUPPORT.md: Add qemu-depriv section > > Signed-off-by: George Dunlap <[email protected]> > --- > Changes since v3: > - Moved from the qemu-depriv doc patches. > - Reword to include the possibility of having a non-dom0 "devicemodel" > domain which may want to be protected > - Specify `Linux dom0` as the currently-tech-supported window > > CC: Ian Jackson <[email protected]> > CC: Wei Liu <[email protected]> > CC: Andrew Cooper <[email protected]> > CC: Jan Beulich <[email protected]> > CC: Tim Deegan <[email protected]> > CC: Konrad Wilk <[email protected]> > CC: Stefano Stabellini <[email protected]> > CC: Julien Grall <[email protected]> > CC: Anthony Perard <[email protected]> > CC: Ross Lagerwall <[email protected]> > --- > SUPPORT.md | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 4f203da84a..1f0f5857a7 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -525,6 +525,26 @@ Vulnerabilities of a device model stub domain > to a hostile driver domain (either compromised or untrusted) > are excluded from security support. > > +### Device Model Deprivileging > + > + Status, Linux dom0: Tech Preview, with limited support > + > +This means adding extra restrictions to a device model in order to > +prevent a compromised device model from attack the rest of the domain
s/attack/attacking/ Paul > +it's running in (normally dom0). > + > +"Tech preview with limited support" means we will not issue XSAs for > +the _additional_ functionality provided by the feature; but we will > +issue XSAs in the event that enabling this feature opens up a security > +hole that would not be present without the feature disabled. > + > +For example, while this is classified as tech preview, a bug in libxl > +which failed to change the user ID of QEMU would not receive an XSA, > +since without this feature the user ID wouldn't be changed. But a > +change which made it possible for a compromised guest to read > +arbitrary files on the host filesystem without compromising QEMU would > +be issued an XSA, since that does weaken security. > + > ### KCONFIG Expert > > Status: Experimental > -- > 2.19.1 > > > _______________________________________________ > Xen-devel mailing list > [email protected] > https://lists.xenproject.org/mailman/listinfo/xen-devel _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
