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. -- Cheers, David
