Re: [PATCH 7/8] qemu-options: document -compat insecure-input parameter

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Oct 29, 2026 at 03:13:51PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Thu, Oct 29, 2026 at 07:52:36AM +0100, Markus Armbruster wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> 
> >> > This adds documentation for the previously added 'insecure-input'
> >> > parameter to -compat, which controls policy for insecure
> >> > configuration requests.
> >> >
> >> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> >> > ---
> >> >  qemu-options.hx | 22 +++++++++++++++++++++-
> >> >  1 file changed, 21 insertions(+), 1 deletion(-)

> > If we put a check in qdev_realize(), then we need to add annotations
> > for *all* types, before the -compat insecure-input=....  option is
> > viable to use. That requires a much bigger effort to mark all types.
> >
> > In the 12.0 dev cycle, my intention is to
> >
> >  a) Expand ".secure = true" markers to all parents of leaf node types
> >     marked secure, and enforce them.
> >  b) Expand ".secure = true" markers to all built-in devices that are
> >     indirectly created by a leaf node type marked secure, when
> >     -nodefaults is present
> >
> > Once (b) is done, then qdev_realize() will likely be the better place
> > to put the policy check.
> 
> Let's see whether I got this.
> 
> * A type can be known to be secure, known to be insecure, or unknown.
>
> * Exactly the types known to be secure are marked secure.  Thus, the
>   policy check must treat known to be insecure and unknown the same,
>   which makes sense.

Yes, we're explicitly not distinguishing 'insecure' vs 'unknown' either
internally or externally. Something is either explicitly marked as secure,
otherwise it is insecure.

> * We start with all types unknown.

aka all types are insecure.

> * To move a type from unknown to known, we need to examine it.
>   Examining all types in time for the next release is infeasible.  Even
>   examining all types usable with a useful set of machines is
>   infeasible.  What is feasible is examining a useful set of types
>   available with certain user interfaces, so that's what we did.

Yes.

> * We check the policy in these interfaces only.  This lets users
>   restrict these interfaces to known secure types, which is useful.

Yes.

> * However, types created differently get a blanket exception.  Not
>   ideal, but no worse than before, unless the new policy creates a false
>   sense of security.  The best we can (and should) do about that is to
>   clearly document the policy's current limitations.
> 
> Right?

Yes.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|