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
