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

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

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.

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

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