Re: [PATCH v2 00/32] Encode object type security status in code

> Our docs/system/security.rst file loosely classifies code into that
> applicable for 'virtualization' vs 'non-virtualization' use cases.
> Only code relevant to the former group is eligible for security
> bug handling. Peter's recent proposal pointed out that we are
> increasingly hitting the limits of such a crude classification
> 
> Michael suggested that with the increased complexity, docs are not
> going to be an effective way to convey the information, and we
> need to re-consider embedding this info in code.  This also allows
> users to validate a configuration's security status when starting
> a guest, or modifying a running guest.
> 
> This series is an attempt to start the embedding process.
> 
> Probably I should split in multiple series. One introducing the
> overall framework, and then multiple series doing type annotations,
> as the latter really need to be CC'd to maintainers, but the CC
> list would be way too huge on this combined series. At least this
> combined series shows what the real world implictions of this code
> approach will be though.
> 
> It starts with QOM, adding a "bool secure" property to the
> TypeInfo struct, which get turned into a flag on the Type
> struct. This enables querying any ObjectClass to ask whether or
> not it is declared secure.
> 
> By only using a single boolean flag, at runtime we are unable
> to distinguish between "marked insecure" and "no decision,
> implicitly insecure". As such, all our existing code is
> initially considered insecure, except for that which gets
> explicit annotation.
> 
> The "-compat" argument gains a new parameter
> 
>   * insecure-types=accept|reject|warn
> 
>     The default 'accept' preserves historical behaviour of
>     anything being permissible. The other two options both
>     identify use of types that are not explicitly marked
>     as secure.
> 
> The code annotations are useful immediately, but to make the
> new -compat switch useful, we need to annotate as much as is
> possible. This series makes a strong attempt to do that across
> a large subset of the codebase. My guidance was to mark enough
> as being 'secure', that a downstream RHEL build of QEMU would
> have explicit anntation of most of its devices, with most being
> secure given they target virtualization use cases.
> 
> This annotation is 90% complete for the x86 target, but more
> work is needed to finish it and then address the arch specific
> devices for arm, ppc, s390.
> 
> Example: TCG is explicitly insecure, KVM is explicitly secure:
> 
>   $ qemu-system-x86_64 -display none -compat insecure-types=reject -accel tcg
>   qemu-system-x86_64: -accel tcg: Type 'tcg-accel' does not provide a security boundary to protect against untrusted workloads
>   $ qemu-system-x86_64 -display none -compat insecure-types=reject -accel kvm
>   ^C
> 
> Example: isapc machine type is explicitly insecure
> 
>   $ qemu-system-x86_64 -display none -compat insecure-types=reject -machine isapc
>   qemu-system-x86_64: Type 'isapc-machine' does not provide a security boundary to protect against untrusted workloads
> 
> Example: checks also apply in HMP, ne2k_pci is insecure
> 
>   $ ./build/qemu-system-x86_64 -display none -compat insecure-types=reject -monitor stdio -accel kvm
>   QEMU 10.1.50 monitor - type 'help' for more information
>   (qemu) device_add ne2k_pci
>   Error: Type 'ne2k_pci' does not provide a security boundary to protect against untrusted workloads
> 
> Example: checks also apply in QMP:
> 
>   $ ./scripts/qmp/qmp-shell-wrap qemu-system-x86_64 -display none -compat insecure-types=reject -accel kvm
>   Welcome to the QMP low-level shell!
>   Connected
>   (QEMU) device_add driver=ne2k_oci
>   {"error": {"class": "GenericError", "desc": "Type 'ne2k_pci' does not provide a security boundary to protect against untrusted workloads"}}
>   (QEMU) device_add driver=virtio-net
>   {"return": {}}
> 

I'd really like to have this already to help us do some security triage!
The framework looks fine to me. The annotations will require a bit of
discussion, probably.

please make a v3

-- 
Marc-André Lureau <[email protected]>