Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size

From: Carlos Bilbao

Date: Fri Jul 17 2026 - 23:31:21 EST

Hey there,

On 7/17/26 06:08, Michael S. Tsirkin wrote:
On Fri, Jul 17, 2026 at 02:07:50PM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 17, 2026 at 06:52:46AM -0400, Michael S. Tsirkin wrote:
On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote:
On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote:
On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote:
On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote:
On 7/17/26 07:48, Michael S. Tsirkin wrote:
On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote:
Or do we just always trust virtio mem devices explicitly?
It's hard for me to understand where we draw the line, really.

But maybe MST can clarify what we care about in virtio world where the
hypervisor is fully in charge of the device,
Generally:
- The guest is expected to whitelist drivers (most drivers have not
been audited).
But even if you audited your driver, who makes sure that we consider all ways
where the device could mess with us?
A lot of this is up to a correct setup. For example, make sure all
filesystems are encrypted and refuse to mount unencrypted ones.

Something feels off here.

Handling selected out-of-spec scenarios like this feels like a band-aid. Happy
to be corrected.
Well Documentation/security/snp-tdx-threat-model.rst puts it like this:
It is important to note
that this doesn’t imply that the host or VMM are intentionally
malicious, but that there exists a security value in having a small CoCo
VM TCB.

and

While traditionally the host has unlimited access to guest data and can
leverage this access to attack the guest, the CoCo systems mitigate such
attacks by adding security features like guest data confidentiality and
integrity protection.


now, when we are talking about "mitigation" it is indeed becoming a bit
murky.


For me, a rule of thumb I came up with is that if the validation happens
to also be helful for users e.g. to work around buggy devices,
or maybe because we feel failing gracefully is nice because this
will allow to later make use of this config and old drivers will
fail but at least not panic, then it is good to include.
Why not do what USB does? Don't trust the device until AFTER probe()
succeeds? All of the needed checking should happen before then, as that
is a "slow path" so lots of validation and the like can happen at that
point.

After that, during the normal data paths, after the driver is bound,
trust it all you want as attempting to validate every single packet is
just going to be impossible.

thanks,

greg k-h
People do expect that data path validation at this point.
Ok, so you want this patch :)

And more, as you need to treat everything from the host as "untrusted",
and it must be "verified".
Well. First it's not me) Second it's only specific configurations -
for example there's no short term plan to validate filesystem code, people
are expected to rely on encryption. The reasons have more to do
with the available manpower than anything else.
Sure, but again, for subsystems, you have to define your threat model as
the LLMs are churning against the code base and coming up with lots of
crazy ideas if a device should or should not be trusted and spitting out
patches and reports like the ones that are in the first few patches of
this series.

So please, pick a model, let's document it, and go with that. I am
getting directly conflicting responses here.

thanks,

greg k-h
Supposed to be this one:
Documentation/security/snp-tdx-threat-model.rst

what is missing?
A policy decision that needs to be made. All that document does is
describe a bunch of different "threats" yet does not decide what to do
about them at all from what I can tell.
That would be this section I think:

The **Linux kernel CoCo VM security objectives** can be summarized as follows:

it does, indeed, not go into detail about how to interact, safely,
with untrusted entities. Does it really need to be spelled out?

And that's just for one subset of the CoC world, right? Is that
something that all virtio drivers need/want to care about?
What is missing, and what you seem to be asking for, is an opinionated
stance on which drivers we care about in this world?
True.
coco guys tried to annotate drivers at some point to do exactly that.
this was rejected upstream from the position that this is not
different from handling buggy hardware, and just to fix all drivers.
so it's up to users, and I guess for virtio the answer is yes
with some exceptions because we don't have a better answer right now.

So I don't see a real answer to the "does Linux trust the host to give
you good data or not" question in that file, am I missing it?

thanks,

greg k-h
This? Note the last sentence.

The **Linux CoCo VM attack surface** is any interface exposed from a CoCo
guest Linux kernel towards an untrusted host that is not covered by the
CoCo technology SW/HW protection. This includes any possible
side-channels, as well as transient execution side channels. Examples of
explicit (not side-channel) interfaces include accesses to port I/O, MMIO
and DMA interfaces, access to PCI configuration space, VMM-specific
hypercalls (towards Host-side VMM), access to shared memory pages,
interrupts allowed to be injected into the guest kernel by the host, as
well as CoCo technology-specific hypercalls, if present. Additionally, the
host in a CoCo system typically controls the process of creating a CoCo
guest: it has a method to load into a guest the firmware and bootloader
images, the kernel image together with the kernel command line. All of this
data should also be considered untrusted until its integrity and
authenticity is established via attestation.


I'm glad you're finding this document helpful, it took us massive
back-and-forth to get somewhere everyone was happy.

Here's my 2 cents on this debate, if I may. I think defensive programming
is always a positive, and we don't just say, "the spec disallows it".

Historically, one of the biggest criticisms of coco, especially around
device hardening, was that there were too many values that a
malicious/buggy device could misreport, making it a losing battle. That is
no longer the case with LLMs, and we have the advantage (and challenge) of
open-source dev, which allows us to receive many of these fixes "for free".
If others want to burn their tokens, let them :)

Thanks,

Carlos