On Mon, Jul 20, 2026 at 08:57:13AM +0100, David Hildenbrand (Arm) wrote:
> On 7/18/26 18:07, 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.
> >
> > 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.
>
> "silly" is the right word.
"silly" in what way?
Seriously, I'm trying to figure out what you all care about here and
what exactly the threat model you want this driver to work in, and I'm
getting conflicting answers.
Either you all do worry about the "device" sending bad data and want to
protect from that, or you don't and you trust it. Pick one please so
that we know how to deal with these bug reports we are getting.
For example, for USB we have said our threat model is:
- we do NOT trust the device before a driver is bound to the device,
so if a malicious device can do something to the kernel, the kernel
needs to be fixed.
- During the probe() call for a USB driver, the driver does NOT trust
the device, and again, anything a malicious device can do to the
kernel, the kernel should fix.
- After probe() for a USB driver succeeds, it's up to the driver if it
wants to validate all data coming from the device or not. Right
now, in general, the kernel trusts the device at that point in time
so additional checks are discretionary and at the whim of the
maintainer.
For that last point, I will note that some BIG users of Linux (i.e.
billions of Android devices) still explicitly do NOT want to trust the
USB device at this point in time, and are relying on the kernel to
protect the system from bad devices. In that case, various patches have
been taken to different drivers and subsystems to play whack-a-mole on
while Android gets their act together to finally come up with a solid
defensive plan (like ChromeOS has had for a decade.) It will be seen
which happens first, all drivers are properly fuzzed and fixed up, or
Android gets their act together and finally fixes their b0rked system
trust model. I think Android management is relying on the kernel
community to do the kernel work as they keep refusing to staff the
userspace work that they need to do here...
And yes, I really need to write this up in a more solid document for USB
and get it into the tree, but at least this email thread has forced me
to write down the above :)
So, again, for virtio drivers, what exactly do you all want to say is
your threat model that the drivers need to handle? Can you all agree on
something please? Otherwise, for new developers like Hari, this is
totaly confusion as to what they should be doing.
thanks,
greg k-h
