From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 88C6130D3F5 for ; Sat, 18 Jul 2026 17:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784396491; cv=none; b=qcsPeZV43ueFJP8H6v+1JknBw2WZ0b1TrBkoOxrHtYkAS8FVTc39UFC8Z0qp6ZFhkqwuWBxbIyUAod6XgwB6Jos5UhgcQA4WR0fPluBawsYyrGHK8FIvyOpDpCaHOVAIEbD/VSsdwBIEVBcb9vHgD1KxTq4M7fmHqAZ5Lbwsb0I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784396491; c=relaxed/simple; bh=CEpVNIMFamK8ZFZw4YMxNorECvmbWE2CGRI+ZPpAoZk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=csUn1Hg9T3pHVkvvt8zEfpMzFh9nlpp/oVem64FcltuO+vgJSf0/A0A4qv+yaoly9LzR2Da/IgnIDjtgOWRVVHPTqc1FJpKwC6oGyHbVTQhnlVhhcIfD5pjr3uDHlC0stTGaNzbN5Q5NcThpVoH+ebpwmVM23McuUl3pKj3alT4= 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=V4bE85Qe; arc=none smtp.client-ip=209.85.210.172 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="V4bE85Qe" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-8485bd28dd0so10449957b3a.2 for ; Sat, 18 Jul 2026 10:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784396490; x=1785001290; 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=1FYkIyXnGh51CvHiVgoa6lNBE/dJN10l2yCF+0lEhds=; b=V4bE85Qe5Q8zrO1tklzHwOfQEEkOAedsgJavi/Mme7GWSD9SHeDTdoKGF4KIZzl6+M M04DZsVIHeTrGWIRkcDAs7T2h8L9+cYyMbgkXve69JlhVW35OQqQ9AIT19RcLT3WErRs k7I/U3hgbL8ovXDBdQ1rjY8uyrJDC+UuG/dwoiGeOcS7pGOWn/5Rm6oIMGe5Jl+GpQKK J6J49bndTUqmgEZlbPjbRGfPTgWdlgI6yYJJcOvKkby4AbYMjJpAsBG1iUUghEAqCMwS lyftVJ9ejbsWqmAppauNaIyu5+yUW1AJ4VFKYmOYArfT8L7owFAV/jjkdAtcr0lcdcGp 6vIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784396490; x=1785001290; 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=1FYkIyXnGh51CvHiVgoa6lNBE/dJN10l2yCF+0lEhds=; b=q7k251fzmL5mTpFp5b6FvDYE7yAAht4jIzE8o8ATVviTsVjPKmqVHkSdwpHsz1/mEV KoesfYAHUuj7qr2LbrX0pzP/34LtAIjP8UAL0f7/w3D0RHQ+10Fmx/Xc/8NSaziuV6L6 060kO5QJf8/IOh3uTg2slhUWlZAB8hR8uuO+654eHtmFGq+TykBPPX7NgrPFY/w1o4D/ XOrNRHppU8G3+4e7R6TtqVelkBaMqouFmrm2cI+6RTaXwssjBPNMWgyvfx/OsJW1UxIT 87R5QDxd/L0nXN2fq6Lfg9HlywwXgKQyRCewfk3OEi+IDIuAq0A9+WCEC+UTQbATkPJP iLqA== X-Forwarded-Encrypted: i=1; AHgh+RqBhN/SYE69rssykMlOnRZPATIsLkOX/PvVboyR6RlD44FkrWMCF5le44lqg+Zic2bllI0xu2+cRO9JAv4=@vger.kernel.org X-Gm-Message-State: AOJu0YycNo8J76ff/fbzwurA/m+n+CvIlcCJeIl0DY2Vn54du0dvhH8+ c+Exea/kUEAsOSk2q8MGMRIYn2YhNYpM3vTn6z2w71zqxc9tggoNxXIQ X-Gm-Gg: AfdE7cljxAHQNylmWdvFOypMDpCKml6N/3xdq0bSFQU1MSTcYMBgn+voiff/P9vc8dJ jDhxMCSkmJxeUIDRdFgCJohosG/n6fzU0n12aStDribGzpBrlzjUMw1Qiukj4mQTbodjQbpwU+C PUSPJBpPzarclLN7cnYwzun37OKQ1jPF3c3QZaTZ0KS56mjzlzoQ56k28YbTNNTEAH0/9OD+M3n JkDro5MQ2j8Xhkt1K+9rHIMs9UU5qkSKTVaq94zcCBTAdlv+B1muewlMsavZ0ond8vYNwIhco78 /yomY40b6vPYRdrRFWrnR5+KjYjKx7n20ISsPChvTngW7DbtxiuJFGZC6CPxzoDkiQTQoqlqOJ0 twf5UCW5LH3F7Ff3+K4fU2lXdTI9OXih7EnDlY77r7Jn+dMUrhVMVaxFEZ+qa7CKpugoQGp7DVx KDz+Vf3J3AoxkmhAIwNrM= X-Received: by 2002:a05:6300:2284:b0:3c0:9c1a:8943 with SMTP id adf61e73a8af0-3c3ada5be63mr8296643637.75.1784396489817; Sat, 18 Jul 2026 10:41:29 -0700 (PDT) Received: from [192.168.86.23] ([136.25.189.61]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31429fdcaefsm19500844eec.10.2026.07.18.10.41.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jul 2026 10:41:29 -0700 (PDT) Message-ID: Date: Sat, 18 Jul 2026 10:41:26 -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: "Michael S. Tsirkin" Cc: Greg Kroah-Hartman , "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: <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> <20260718131715-mutt-send-email-mst@kernel.org> Content-Language: en-US From: Carlos Bilbao In-Reply-To: <20260718131715-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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