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

[Carlos Bilbao <carlos.bilbao.osdev@gmail.com>]

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

>
>
>