On Thu, Oct 23, 2025 at 02:22:12PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > The description of virtualization vs non-virtualization use > > cases is a crude approximation of the security characteristics > > of QEMU devices. > > > > Document how QEMU can be probed to obtain information on the > > security status of type classes, and how policies can be set > > to inform or control their usage. > > > > Signed-off-by: Daniel P. Berrangé <[email protected]> > > --- > > docs/system/security.rst | 43 ++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 43 insertions(+) > > > > diff --git a/docs/system/security.rst b/docs/system/security.rst > > index f2092c8768..cda4bae6db 100644 > > --- a/docs/system/security.rst > > +++ b/docs/system/security.rst > > @@ -49,6 +49,49 @@ Bugs affecting the non-virtualization use case are not > > considered security > > bugs at this time. Users with non-virtualization use cases must not rely > > on > > QEMU to provide guest isolation or any security guarantees. > > > > +Security status reporting > > +''''''''''''''''''''''''' > > + > > +QEMU is progressively working to annotate object types to explicitly state > > Suggest "The QEMU project is working" > > > +whether they are considered to provide a security boundary or not. > > + > > +It is possible to control or identify the usage of types that do not offer > > +an explicit security boundary using the ``insecure-types`` parameter to the > > +``-compat`` argument, which accepts three values: > > + > > + * accept: usage of any type will be permitted. This is the current > > + and historical default behaviour > > + * warn: usage of types not explicitly declared secure will result > > + in a warning message, but still be permitted. > > + * reject: usage of types not explicitly declared secure will result > > + in an error message, and will not be permitted. > > + > > +The compatibility policy will be honoured both at initial startup of > > +QEMU and during any runtime alterations made with monitor commands. > > This is about QOM. It doesn't cover security boundaries outside QOM, > e.g. in block backends. I think we better make this limitation quite > clear here.
I was anticipating perhaps future work to bring this to non-QOM stuff too like the block backends, but I guess we can mention QOM now, and change it later if needed. > > +Machine type, accelerator and device security status can be queried > > +using ``-machine help``, ``-accel help`` and ``-device help`` command > > +line options respectively. > > + > > +The setting of the ``.secure`` field at the time a type class is > > +declared in the code will determine whether bugs are eligible to > > +be considered as security bugs: > > + > > + * Explicitly declared ``.secure = true``: security bug process > > + applies, eligible for CVE assignment > > + * Explicitly declared ``.secure = false``: security bug process > > + does not apply, ineligible for CVE assignment > > + * No declaration of ``.secure`` property: follow the security > > + bug process initially. The virtualization vs non-virtualization > > + use case classification will be evaluated during bug triage > > + to determine whether to continue the security bug process, > > + or switch to the regular bug process. > > Should this evaluation result in a declaration of .secure? Yeah, that would be good workflow. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
