From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A31D52EDD69 for ; Sat, 18 Jul 2026 17:07:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784394456; cv=none; b=m1aZRhvjS6GSD4mEvAPys3B9j7ZjFxtYZ3bYxAqVd3cFIPCFbgqQtHld7SF/27kQzYOtOGKbE238N6adT5h5ORxWRF+LKmI7Umf2TqduQCIBXLhm+qPQbxDsAV7MNgHrcjnh6RSisxOdLV0qisJcrXn76QW+s04YntyuaQNJc8Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784394456; c=relaxed/simple; bh=9oenhziDUtv13zV3obwo8PSJq5KghJW/R1qHQeEgEBs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jHL7WpBGji1k2hMxe7qLoFLj8jepE1WQYtiDJuSAYnGm/gzNO4WwOGNs1ofII66FD3LOxS4o01pktxYycNProXY/nvxXmCA6qbXlLpu/0rGBSLpHlPIybjjehurYu1fWXoTtutH52D+tXtJvVcvOgYk4gVvmRpi4cmVQu+WqHdg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NKY6lR76; arc=none smtp.client-ip=209.85.215.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NKY6lR76" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-ca2fad0ae38so6922243a12.3 for ; Sat, 18 Jul 2026 10:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784394454; x=1784999254; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=6AMl0iO86IWTwZS9RKYqeagiNPn+Qxng/j1BN8a1GWs=; b=NKY6lR76OxxL4a5H+VZoYrZsqo50NqXM0yU1FMBm+H78EeBlfoa8W5ECtm7TPtOcqu Zk9z6PyuJkDQkikcjD2CgwlMCRPVfxt/olqo2HpwSv3IBhtTLOkympWBIOB4RHfNdMfY 3SZU2+RYNxvIDqtAKrjAHhOtuY2aZDtA9m+RCRzP06/e1AIWXPRJLi5JilS/9tWkJQik aTqo6LmFrKUc2caWuUWLq+XZ7C1M8OvNFMw+EHZ9ym9B8Ojc5gm9/0SbOMn3XdchPArd HW+xspKNM6eyci12siioi9xU0mWTtT0HBFczM3m/PJ5BVGAxohQvK7u2yhJyvPvHApZV XJig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784394454; x=1784999254; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6AMl0iO86IWTwZS9RKYqeagiNPn+Qxng/j1BN8a1GWs=; b=KUhqob7PxB5PSuxFipYg/vXtceDaVA8luqhvcZ7ptZzUeKsgBU0mi7U2sKXZ/swah3 1Ey+3/XrFvIkP7Ik1X/HO2pMSzrCZChdYjBrwdML/+wz5KWmC17jsBnisD2u9uZ31opy z3gvN75NufobiAo/xO0L0yJtNKWNkXsZ5P9phYnaa2cSzP3Uh8wxoADCLIibf7hWkEjR ImnCnyGjTSXtS193ZcFOC1WBOblgTKT5Bv0SZ+MpeefaOTPB09MKy6+famb6kFRY88oH S9bFkQ9x1hVdzE3HkeZffdlnjjknBmX2k3va41YFKP1hf0KSihe14Hb3YIxzL5GLrLco Hu2Q== X-Forwarded-Encrypted: i=1; AHgh+RokpSgyKX56Q+CtPN3V7TjfNg+eeZJzv1N09XNOCtQU7eBhgu+LZfpjJAXLv4YwQ/h3Fy+u//Au9N9CZsw=@vger.kernel.org X-Gm-Message-State: AOJu0Yyj0Xzf7fkoDIkkVj0HIr9SF8Asv5xYIZIqIQFPD6cLoMv7zj/f AV0z/NA1DUd6nl0EgBgNOqfYbTYEhUg6lgF27DUILms1JJt6mxU1Fkci X-Gm-Gg: AfdE7cnN8t/lCAdMYyU5b8ocBtOfIGD1dqRpe1yQYblrp2SurYrGgMmXZ3yR34ZxO+5 H04Klc1mamJlr7/wwmUEr2qb1HdFwafYsc+lc4E58T0V6yV+K/WEM7ZPlCPzjvbldxA2m1ALis6 oNXA1xT0UalTrtqKfblPtX1CnFfuvDfqV0QWHDK9h9aP7wNyCTMzXNBYzAtrh8wIPBxyUWty096 6qPnJsK+bi3gmsKZYdORHodA4cXJ8H5YqgCCkkbjwwrQRAf3eBqa167Fyl6EK97bmdlOVf+571x +izFs3AjHK9xOfHpzjZRzFgKDilDRG68Eb6jGVok8XGcOvlVtBsibiCWXIRpfc/3DifpIDFpb/H mtel7sloG/5r15Myj9Gd0WjrQCcKEJruZMmmcLOrA1LFGW2GJPxNsjvBxKnkSR395X4KBRVNT/r uQFxqHuFH6tmMGK46TsQM= X-Received: by 2002:a17:90b:2f85:b0:381:a766:efc9 with SMTP id 98e67ed59e1d1-38e4b4227b8mr7057120a91.7.1784394453960; Sat, 18 Jul 2026 10:07:33 -0700 (PDT) Received: from [192.168.86.23] ([136.25.189.61]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1dde81sm36015303eec.21.2026.07.18.10.07.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jul 2026 10:07:33 -0700 (PDT) Message-ID: Date: Sat, 18 Jul 2026 10:07:30 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size To: Greg Kroah-Hartman Cc: "Michael S. Tsirkin" , "David Hildenbrand (Arm)" , Hari Mishal , Jason Wang , Xuan Zhuo , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, elena.reshetova@intel.com, huster@cs.uni-goettingen.de, mhollick@seemoo.de, jiska.classen@hpi.de References: <20260717044019-mutt-send-email-mst@kernel.org> <2026071746-deviation-clad-1712@gregkh> <20260717060822-mutt-send-email-mst@kernel.org> <2026071757-grout-composer-165d@gregkh> <20260717061901-mutt-send-email-mst@kernel.org> <2026071724-asleep-pedigree-ea54@gregkh> <20260717065219-mutt-send-email-mst@kernel.org> <2026071759-thermal-synopsis-7568@gregkh> <20260717085838-mutt-send-email-mst@kernel.org> <1fe328d1-edf9-4e72-a145-be74ede20e60@gmail.com> <2026071803-passage-dares-8240@gregkh> Content-Language: en-US From: Carlos Bilbao In-Reply-To: <2026071803-passage-dares-8240@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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