On Thu, Oct 29, 2026 at 03:13:51PM +0100, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > > On Thu, Oct 29, 2026 at 07:52:36AM +0100, Markus Armbruster wrote: > >> Daniel P. Berrangé <[email protected]> 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é <[email protected]> > >> > --- > >> > 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 :|
