From: Greg Kroah-Hartman <[email protected]> Sent: Friday, July 17, 2026 7:31 AM > On Fri, Jul 17, 2026 at 09:08:23AM -0400, 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? > > Seems like it as I didn't figure it out at all :) > > > > 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. > > Yes. > > > 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. > > Ok, so back to the original question here: > > > > 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. > > Great, so you are saying that we need to fix any bug found where a host > could be sending "bad" data over the virtio path before, and after, the > driver is bound to the device. That's a solid answer, and let's let the > LLMs run with that! >
FWIW, Hyper-V VMBus drivers in Linux use this same threat model, with the same conclusions about data validation. The details are in Documentation/virt/hyperv/coco.rst. See the Section entitled " Guest communication with Hyper-V". Let me know if you've come across potential data leaks or corruption modalities in the virtio code that might also be applicable to the VMBus drivers, that aren't already mentioned in that documentation. Michael
