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

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

Hello Michael,

On 7/18/26 10:21, Michael S. Tsirkin wrote:
> On Sat, Jul 18, 2026 at 10:07:30AM -0700, Carlos Bilbao wrote:
>> On 7/17/26 22:29, Greg Kroah-Hartman wrote:
>>
>>> On Fri, Jul 17, 2026 at 08:31:09PM -0700, Carlos Bilbao wrote:
>>>> 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 :)
>>> I have lots of tokens to burn :)
>>>
>>> So along those lines, any suggestions on how best to fuzz these code
>>> paths?  Any workloads you all use for testing that I can take advantage
>>> of?
>>
>> We've the virtio-mem config struct layout and the kernel source, so for
>> obvious fixes like a NULL check, static analysis is better than fuzzing.
>> Claude took a few mins to find me two examples:
>>
>> Patch 1: virtio-mem: reject non-power-of-two device_block_size
>> This one is for virtio_mem_init() to check if
>> !is_power_of_2(vm->device_block_size)
>>
>> Patch 2: virto-mem: validate region_size and usable_region_size
>> THis one checks region_size != 0 and vm->usable_reion_size >
>> vm->region_size.
>>
>> An endless factory of "silly" checks like these are low hanging fruit.
> At the same time, these checks don't actually help within the coco
> threat model, do they?
>
>> Now, for harder bugs, looking around for fuzz options, VirtFuzz [1] looks
>> like a great candidate for those interested in pursuing this direction.
>>
>>
>> Their PoC fuzzes wireless/Bluetooth stack, but nothing our AI overlords
>> can't quickly adapt for virtio-mem and other virtio drivers; the JSON
>> definition to describe device behavior is easily extensible. Their threat
>> model [2] describes an external attacker, but in the context of coco, the
>> virtio device itself is the attacker.
> What we need, however, is to exclude DoS attacks - these are outside the
> threat model. If people try to address all DoS attacks uncritically we
> just get a churn of changes which just might introduce issues of their
> own.
>
> Example:
>
> 	BUG_ON(!is_power_of_2(....));
> panics, non exploitable.
>
> 	if(!is_power_of_2(....))
> 		goto error;
>
> can become exploitable if the cleanup is done wrong.


Yes, you are 100% technically right about the scope of the threat model.
DoS is out of scope because it is a fundamentally unreachable goal; the
cloud provider can always just "pull the plug". The dangers of
"vibe-coding" you point out are real, over-eager LLMs fixing up and down
will create new vulnerabilities in complex cleanup paths. Also, TBH, I
sympathize with a maintainer's disinterest in reviewing a million stupid
checks.

But, to play devil's advocate: this assumes a missing check
like is_power_of_2 only ever leads to a benign crash, rather than already
cascading into an unknown, exploitable state down the line.

So these checks are not _just_ to prevent DoS!

Anyhow, this is the exact justification for VirtFuzz. If your main concern
is that adding validation checks might introduce subtle exploit paths in
the error-cleanup code, VirtFuzz and tools like that, can fuzz those new
paths exhaustively. It gives the automated safety net needed to scale coco
device with as little regressions as possible.


> 		
>
>
>>   Here's a vibe coded PR of what I mean:
>>
>> https://github.com/seemoo-lab/VirtFuzz/pull/7
>>
>> CCed the creators/authors, thanks for open sourcing this!
>>
>> Thanks,
>> Carlos
>>
>> [1] https://github.com/seemoo-lab/VirtFuzz
>>
>> On 7/17/26 22:29, Greg Kroah-Hartman wrote:
>>
>>> On Fri, Jul 17, 2026 at 08:31:09PM -0700, Carlos Bilbao wrote:
>>>> 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 :)
>>> I have lots of tokens to burn :)
>>>
>>> So along those lines, any suggestions on how best to fuzz these code
>>> paths?  Any workloads you all use for testing that I can take advantage
>>> of?
>>
>> We've the virto-mem config struct layout and the kernel source, so for
>> obvious fixes like a NULL check, static analysis is better than fuzzing.
>> Claude took a few mins to find me two examples:
>>
>> Patch 1: virtio-mem: reject non-power-of-two device_block_size
>> This one is for virtio_mem_init() to check if
>> !is_power_of_2(vm->device_block_size)
>>
>> Patch 2: virto-mem: validate region_size and usable_region_size
>> THis one checks region_size != 0 and vm->usable_reion_size >
>> vm->region_size.
>>
>> An endless factory of "silly" checks like these are low hanging fruit.
>>
>> Now, for harder bugs, looking around for fuzz options, VirtFuzz [1] looks
>> like a great candidate for those interested in pursuing this direction.
>>
>>
>> Their PoC fuzzes wireless/Bluetooth stack, but nothing our AI overlords
>> can't quickly adapt for virtio-mem and other virtio drivers; the JSON
>> definition to describe device behavior is easily extensible. Their threat
>> model [2] describes an external attacker, but in the context of coco, the
>> virtio device itself is the attacker. Here's a vibe coded PR of what I mean:
>>
>> https://github.com/seemoo-lab/VirtFuzz/pull/7
>>
>> CCed the creators/authors, thanks for open sourcing this!
>>
>> Thanks,
>> Carlos
>>
>> [1] https://github.com/seemoo-lab/VirtFuzz
>> [2] https://www.computer.org/csdl/proceedings-article/sp/2024/313000a024/1RjEa0y9RMQ
>>
>>
>>> thanks,
>>>
>>> greg k-h
>> [2] https://www.computer.org/csdl/proceedings-article/sp/2024/313000a024/1RjEa0y9RMQ
>>
>>
>>> thanks,
>>>
>>> greg k-h


Thanks,

Carlos