From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6828E3F3281 for ; Thu, 23 Jul 2026 23:59:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784851160; cv=none; b=I/UA5thfhqjJFhO5QGzrg8RUysP2jDIeDYSDQAWv535TGUfqVowxoYNa+OGUzQ4g85Eo/QuR4bijBzdpLRPLVDqlSlEM57vWMTu2NnSU0cyzifTEkKwTbDVKC/kRRa8xz/pN3Wos1vcX/zmRoB3Yq2Dtvga+4DizTsucb6Sj5Bk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784851160; c=relaxed/simple; bh=IKxAtZINYxF9GpsCxElzPyG4Yaf1o+nYmZqv96p9RMo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BNQ59ZMHpyhk5yUry4ECl0JjBfEXeanzSECrj/JqKvkzVuIDykmU/g+Q6S0oEZbtYe3MHeqSic1jAHTZaFL4009OLMGBWnqkt6TCGW00xJH+76ixnwu0aX3fFyHzt1g6bifJZXAlh+/iI2yGDpBeDEkYNopAepNjHPCaojsO1R0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dQQX0brd; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=DBe6HG8V; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dQQX0brd"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="DBe6HG8V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784851157; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZEI0aX1+y9xYFrmtNMiKkSHaamceHVFwdAKEA7K4NHg=; b=dQQX0brdnrjymm8uglOTyjWzzK15/wcNZ4APVnMT9Bo78YjmdKDDQeNZngU/5YK3Mch1pB 75qSw1mTvC6Xuyf1SZAcn0psO222xQq0P6eAv44x/NAF3WIk7qDF+jQz/c7FzfYKbDKyWy SZmgA8bdNggS4HaW9sv9m2f5ZawM3rI= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-623-0UUIGJRQPxqO-LskzHwZVA-1; Thu, 23 Jul 2026 19:59:13 -0400 X-MC-Unique: 0UUIGJRQPxqO-LskzHwZVA-1 X-Mimecast-MFC-AGG-ID: 0UUIGJRQPxqO-LskzHwZVA_1784851152 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-47f8158485eso1125353f8f.3 for ; Thu, 23 Jul 2026 16:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784851152; x=1785455952; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ZEI0aX1+y9xYFrmtNMiKkSHaamceHVFwdAKEA7K4NHg=; b=DBe6HG8VtOnG3j34+Jcvj42ZYzIo5PseUtP174WK0+6CE3EOpUqxHh7zpRU6U1pt0J kcy2/MzovBwWw8IGTnC15AoFUpQmaLAgFrUq7vUlstdcFTw8lhjmV45w4heKh3EBx9d1 ty0Tf83mT3FUO112d7fQ9JW9VLoZfsnP9Sid8QBN5Thf0byEYR7CMueAZ3SNXgpK+6w3 EzE5tP6pgfAts3gihAAp0ZC6VJnZvY2TelAr6rNRRb2C9alJ5/AvODyWc1Xc8q7rFqYg gG597Lb/UFx+nHzDQB18BRXvYabtFnMbvcDsjHnwSINk3EKu8us0NGCwhfo7xNZ8vdiX x42w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784851152; x=1785455952; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=ZEI0aX1+y9xYFrmtNMiKkSHaamceHVFwdAKEA7K4NHg=; b=XbAQz5wxOeL5+6U4UVIKnxcVxqeq8WM/kfOi7qjyzQu+Txit6GugAyRJZm4l2jMxpg OiqXIb/lJR2E7DmCFqplnTBbuLwz45pfBUMONLYI9tvdMwlMp9if7wGmVugZvj3n0MQ1 1EXX5mT+GPAqevFa39BFb/O8JdC/H6jvODii3DLjPQ/zDDQnQXrmIshQUXJK6lQpDftJ VU9ipLFzGeEfO4CsvmtA800fDGIj4mYTQdUKXHu6StmFB9URyFvSRK7wt2txlggOOIm3 zQuRUz6sOxIw951O8TmCo40xw7OZlYZTrKbY35CxkWZaJlVa3/P8WVTA7g1C6bmf1VKX 0Qww== X-Forwarded-Encrypted: i=1; AHgh+RphyXy8PQApKQFVa/uiZ0fovoWgwFhSvMv084eqx4EOFzqX5OG5Z808VDxKQKcdTPSSSwtH68arBt0cs7k=@vger.kernel.org X-Gm-Message-State: AOJu0YzDzdOu0+wx4Au4OQ8sFQ59hwCQRSkI2qntlJDql9Ca30wJqL1k V8cOR8P2/WyIavgdaMgFGz6zvIcKo14DRw2QbZ59MPxKztsTygJFa7BHGsThdeTFibBYzwDHV5R DLvVET4/utQ0ZKiHMje91mvxpT7FpM9L0PmQ8vd4WUs7U/KZskL0UJ37jPoLhJek3qA== X-Gm-Gg: AR+sD11jYia4u+eTuv90gLrWL0x1N/pWf2BMMHDuS085eTbilz5i2oN0VYW5j3nn2Em JaqfmCspioStzvn8hA93ksuj5KOUo94HA5ENNe2Zrxmh6j7GL0k+tXRAtVFVvBvdryyQ8HZTakD swHK9uEBuwoPxbW1VWevCcMLPGlzHHTqDCccy4evqgOJ/0mewS9uVSLhELpnxMaq2tx3qiroMDh 0OcaXw6nuI9/feDnlxHhwvtxLFXXB2pFknfHcQIMpNesDm/s7V3wgiN6VDtLCqKtVbMBwIL7Xd6 ajKrYyesz211FJgwG2fZ9rttK4GtfMSDBPvP8eGznlUeWnonCK61JiyXZ+g62Dkv084W9YCoQky Ma47UEcTFqGjzEPxD15y6gw== X-Received: by 2002:a5d:5e87:0:b0:47f:6fe0:294a with SMTP id ffacd0b85a97d-47f8d72ba0fmr6123618f8f.23.1784851152382; Thu, 23 Jul 2026 16:59:12 -0700 (PDT) X-Received: by 2002:a5d:5e87:0:b0:47f:6fe0:294a with SMTP id ffacd0b85a97d-47f8d72ba0fmr6123582f8f.23.1784851151888; Thu, 23 Jul 2026 16:59:11 -0700 (PDT) Received: from redhat.com (IGLD-80-230-37-66.inter.net.il. [80.230.37.66]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85c531afsm19209875f8f.24.2026.07.23.16.59.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 16:59:10 -0700 (PDT) Date: Thu, 23 Jul 2026 19:59:06 -0400 From: "Michael S. Tsirkin" To: Carlos Bilbao Cc: Greg Kroah-Hartman , "David Hildenbrand (Arm)" , Hari Mishal , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , 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 Subject: Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size Message-ID: <20260723195258-mutt-send-email-mst@kernel.org> References: <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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Jul 18, 2026 at 10:41:26AM -0700, Carlos Bilbao wrote: > 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! I don't get it. It's normally for bug reporters to show the problem is real. How about analysing what's going on eh? The situation where a misbehaving hypervisor crashes guest and this is reported as a "security problem" is unsustainable. > > 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. Sorry I'm pretty sceptic how far this will get us, supposedly all virtio drivers have been fuzzed by now. Are we gonnu be inserting specilation barriers around all these "security checks", as one example? If there's something that never happens, I'm okay with just BUG_ON instead of carefully propagating errors all around the place. > > > > > > > > > >  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