From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (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 B21E03E3166 for ; Thu, 23 Jul 2026 23:23:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784849022; cv=none; b=Laq9gPXK1SgdYe+YQTog3doweoHJSvGRvGHHYMCyvuCcN4PQcO438iyS9JbT3iXvThkORQnmuNxYlIjA+vUiQSel7w3KeR8B6fFNYdWDNkQc53nz7jO2gAD0vcHubDdfjipDn4vQQfjyJHYkcmlbjmqUMi6Zjr8/WCbnXZehlUI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784849022; c=relaxed/simple; bh=RCslVQ8rlKf+KIrsldOKN583xnKkZ29q2nJfToVvW2c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BK5Zb7nw+gcDM9fSobfTMWBIlJCTLZJuHsu246w7YhBSfdsUX5xHV0vqKRRhQ786DMZ5bB5TqerSvvl2x+BlvlugXJG3KquyKsW0e0JwDs8TA2kBvpSeBNSg8H3Lh/ubExRGiP+6m50Iq3rhHOc8G7B9KLMktEpMgBfeBd9MB9w= 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=RLeW5liy; arc=none smtp.client-ip=209.85.216.46 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="RLeW5liy" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-38dd55ad76cso902811a91.1 for ; Thu, 23 Jul 2026 16:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784849020; x=1785453820; 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=lqcRKTyLq58dqD717R3/m+4peqMaa1kds05szz65JzE=; b=RLeW5liyLivDFAbnezsjsslSmnDbJnT2PTB2GUl+8hv8a70NYSqfB7ueY3j3s2G32l FByET6braiXb37qNPdVafsnFMkt68rvnwXZvrL38two5Gh0+mkhVkyWSConwW50gIoCB C/qVARFsZb2ANslrKIQOb3wSb6KOyS1voYHzAGKcHdV4Wln3urfVovl66I/XmVNcVEOi f9I761AtTlh33cjUX513ssQylkeOaW9EMF9jaotrwFJGcHnSItNDmYeQaa2N/N28o/jk 14zXB7rFU8uEXZakhj/qoXJ43A65UfOs0zfggwefRZrmwXbKF/XcPyYcSNnqj2SuQxy3 JlUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784849020; x=1785453820; 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=lqcRKTyLq58dqD717R3/m+4peqMaa1kds05szz65JzE=; b=eBkcOxZMBNpGCFPkcwhctemz1/WoECFQogbT4RA1c0H0RQZDTG1H9qgaQvcuwPB1K6 Df4GAUQbdqw7qQWx1UnvKq27BTCkfd/zEz76hT++mTolkuRJgHZNtLFWYHxA5lLdsA3f Oan055nSyIq0O0JxJWYX1e3adebRuApJlI6TbnRwSrWsFOj+rgDsB8SapJX20T2B+jEl ADQwcTpI6xVMfVj2ySjs88O2VjuF6fcjlbnXJNaHokm1jJYf48XqQd8JLNtbNrgZMD69 ZbRd1cD1hIu5UAXEedauzjZmZIiAo2EpcvfUSa3ZDuE2bkZdtS8IgeCkatUvqYZAahtS R2Tg== X-Forwarded-Encrypted: i=1; AHgh+Rqy6RQ88TFvU4kZov1My9SkgpCgArC8+XvA1u283T7fAjHmZAmJS+K/ctC0O7fNUa8tC4EvFhmaf4DvrC0=@vger.kernel.org X-Gm-Message-State: AOJu0YxN5vlD2LGgfBg6u8neYH0DP9uffbIKSHuXblOt0+NVmBnLEzYj c80UolVjIz1a5N0OJosAHGcZ6apKEZ5gdSbBN5uVG86IaPuh5a0YV8Ed X-Gm-Gg: AR+sD10T8Kcucoto/V6r9mf5YKQwwsnASngX7/JXJfV/SoFxVxQbebLxRzgv2uWokPu kuKzlLB5xI5wdotYA8otyoOnG5Mf+uj1562R81bOl2TgF+CSj0jcwCcCPxfQgXOOPOClyYu6601 oYnHUrtUk3crHqxKebN9LYoHtNkUP0a8p4tifLDZoyiIlndWfckvaCzaF9j376bbn+fPVuKAvlQ HrgCttm/GYdyDzBIieYzrx3/MDTx94moIuP1LKQJGPZGkOELCzw7MZQ7XkuoJS1LP8hOt2x4Lsy cg9OYi9GaSZoeC3lTkM4nFfiKaL3bwTHe6HlYGfMMnWev+0DwIc+cZJ8xCtBJaOpNHkmW/kTH0G 5dJkRsGf1F25+ADnROGijutqBSPGMyj1sGyEcT5w3PYgcld3wakeibtLV/onU5Ndo682OmKIaKH kgkFbXHdc6X1ErKykoKKw= X-Received: by 2002:a17:90b:274b:b0:36b:de66:92c3 with SMTP id 98e67ed59e1d1-38ec85060bcmr4678203a91.10.1784849019910; Thu, 23 Jul 2026 16:23:39 -0700 (PDT) Received: from [192.168.86.23] ([136.25.189.61]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13d130262d2sm17551764c88.7.2026.07.23.16.23.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 16:23:39 -0700 (PDT) Message-ID: <2c636784-30c4-4de9-86ef-81c0027a85cf@gmail.com> Date: Thu, 23 Jul 2026 16:23:34 -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: "David Hildenbrand (Arm)" , Greg Kroah-Hartman Cc: "Michael S. Tsirkin" , 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: <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> <9569e577-aa82-4642-b9d9-fd496fc12849@kernel.org> <2026072036-outburst-rebel-c71b@gregkh> <8237ffef-4fb4-40b4-82c3-e9236032ab7e@kernel.org> Content-Language: en-US From: Carlos Bilbao In-Reply-To: <8237ffef-4fb4-40b4-82c3-e9236032ab7e@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/20/26 02:19, David Hildenbrand (Arm) wrote: >>>> 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? >> > As in producing "silly" low-hanging fruit patches that don't move the needle > when it comes to security. > >> 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... > Right, and for virtio devices trusting the device after probe is just extremely > questionable. > > What changes during probe that the device suddenly sends us good data? > > Why would a hypervisor that tried to break us before probe not try to break us > after probe? > >> 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. > Well, I am also totally confused why we end up checking against some MUST > clauses in the spec, but not against others. > > I am very much in favor of making virtio-mem completely safe to use even in > coco, where it is currently not used at all. > > If it's really about "don't let a device trigger any unexpected kernel code > execution by sanitizing all input data", fine with me. We should do exactly > that. Try checking all MUST clauses etc. > > But I don't think doing the "low hanging fruit" adds any security. It should be > done properly or not at all. I think you're mistaken in assuming that these "silly" fixes don't move the needle at all when it comes to security. We can't really quantify these things, and one extra NULL check by itself is probably not going to make a meaningful difference. But, IMHO, this should be treated as the opposite of "death by a thousand cuts", many small hardening improvements, each individually insignificant, can collectively make the kernel substantially more robust over long periods of time. Thanks, Carlos