On 8/9/25 17:15, Daniel P. Berrangé wrote:
On Mon, Sep 08, 2025 at 10:45:40AM -0400, Michael S. Tsirkin wrote:
On Mon, Sep 08, 2025 at 01:50:57PM +0100, Peter Maydell wrote:
Currently our security policy defines a "virtualization use case"
where we consider bugs to be security issues, and a
"non-virtualization use case" where we do not make any security
guarantees and don't consider bugs to be security issues.
The rationale for this split is that much code in QEMU is older and
was not written with malicious guests in mind, and we don't have the
resources to audit, fix and defend it. So instead we inform users
about what the can in practice rely on as a security barrier, and
what they can't.
We don't currently restrict the "virtualization use case" to any
particular set of machine types. This means that we have effectively
barred ourselves from adding KVM support to any machine type that we
don't want to put into the "bugs are security issues" category, even
if it would be useful for users to be able to get better performance
with a trusted guest by enabling KVM. This seems an unnecessary
restriction, and in practice the set of machine types it makes
sense to use for untrusted-guest virtualization is quite small.
Specifically, we would like to be able to enable the use of
KVM with the imx8 development board machine types, but we don't
want to commit ourselves to having to support those SoC models
and device models as part of QEMU's security boundary:
https://lore.kernel.org/qemu-devel/[email protected]/
This patch updates the security policy to explicitly list the
machine types we consider to be useful for the "virtualization
use case".
This use-case sounds reasonable to me. I also imagine that
some machines can get fixed down the road perhaps to
the point where they enter the "virtualization use case".
However, since we are
getting this elaborate, would my old idea of a runtime flag
make sense now?
To recap, the idea was to add a "-virt" flag that will
block any machines, devices and so on not considered
part of the "virtualization use case".
We could also create a mechanism for downstreams to
tweak this as they see fit.
I would not consider "virtualization use case" to be something we
want to represent in code. It was just a crude hack for the docs
to approximate what we wanted to /initially/ aim to support.
The ideal theoretical end state would be for everything to be
in scope for security fixes, but we'll probably never get that
far. The reality is that we have a granular decision likely at
the level of individaul QOM/QDev types.
If we wanted any flag it would be better expressed as something
like "security-boundary=yes|no', and then each object would need
to have a tri-state property "security-boundary=undefined|yes|no".
Initially everything would be in the 'undefined' category and
over a long series of patches we would then reclassify as much
as possible to "yes" or "no".
I find "yes" to give too much trust and fragile, since it is easy
to introduce (security) bug and discover them later, usually too late.
FTR our previous discussion about taintable runtime API:
https://lore.kernel.org/qemu-devel/[email protected]/
.... a mere matter of someone having time to actually do the
work, which is how we ended up with our current fuzzy doc
rather than anything expressed in code.
With regards,
Daniel
