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.133.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 0DFC03546C3 for ; Fri, 17 Jul 2026 13:08:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784293714; cv=none; b=utOlkQ7ST1XvfHGSSuk17gA0pgemjWtrbYe2K1nVdNcx3e5rdwGh64Er9vScl7afotiH6MWUD/+GE761JOg3h0bnI6FuCMhFQovfgk/AX30iX7ViozME0kFA78MJqdJM0gNc0FxzuqmHJyDwTCfkuqcWK+YLa2feYZmBqAbYLRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784293714; c=relaxed/simple; bh=SYBJ8I2vOFE20n9zvoCaJ27qw72MtUpQ5WJZf17afpo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CmfDkZhTzXkCrwyo3eUz2rhcDGT7esjgdQhaX4Ipntzl1ly378i0RyYzB8u71jZJCFaq/WX7aMgCmgfZ9PiO1cU//JPuyGlh4dxqoDiGSJJ/K+blmciOZZDIrgIM6gwGCpMwVfNFJchonYx6UmBiV7h0/JYnde9HO3QCZ0bCMLE= 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=XwtsehLL; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=W4GfS8Ch; arc=none smtp.client-ip=170.10.133.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="XwtsehLL"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="W4GfS8Ch" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784293712; 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=Adg6o3Sp07Mg8EgEzVHcdip9gLyL6+d2pKPLervpt+o=; b=XwtsehLLEb4C9skNKxcXcmu17d+q9T3s/D24Q5463M+x3b1vLkoW+OCr4ACRSi4DsFuFZF tmVG2fpiFgD4K9e0qV+lPIk0Wg3V+PNrt4ujyZ64KmAan08NVwtLxlY49vsTtatZZryO8+ XqiVMvhNQuy/cUGLRJvtHRvJp/LIWcs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-522-ScPbxOoSO1Get9u8eeqAow-1; Fri, 17 Jul 2026 09:08:29 -0400 X-MC-Unique: ScPbxOoSO1Get9u8eeqAow-1 X-Mimecast-MFC-AGG-ID: ScPbxOoSO1Get9u8eeqAow_1784293708 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-472c330e555so3728172f8f.1 for ; Fri, 17 Jul 2026 06:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784293708; x=1784898508; 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=Adg6o3Sp07Mg8EgEzVHcdip9gLyL6+d2pKPLervpt+o=; b=W4GfS8ChPpN5G9/ImeF6bb0RRy0KVs72wcvQuSgasDeON47ZNBuSBHSGYSSjvZ7YWx m4xQvxQpTndrQliSsHlE5DIHM5oh6DB10gx02qzlSsoJPWGcxB5fRlFyrS1GViDYGrO9 SVOvr2/VgC84mpP3U/3lNUjpFMJh0RCML9ZOF7Ylc8jUlTYrXgrIYnVN5Ht4RHL7Oxd1 8QedejRLE1qdpsbYlz3vpy/Je76jl24iU77Q43i0dE4sOXjwpjBORnuu3vYQrqQ75MZF x4OsBWEpjwonMVN2jNwiWS12TteHFm73aKpWl2gOIJFGe0tDKDGbisJCyAq2CaF9R0iM 0+1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784293708; x=1784898508; 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=Adg6o3Sp07Mg8EgEzVHcdip9gLyL6+d2pKPLervpt+o=; b=gC+AwGEW0TiNX9nYbTQfJIXcV8GaS2Gg1WW3VnH+yY0JOBcLeUAsoDxrmYJkFaJj2o bxRCBkFrUSXpMgP868tMJk9j5ljdFCTYo1yJLW7OEYYwbcL0qJZ+rHljaquy0zcGFk72 6KyQFWr7ExLKybAfVyCl/LYp2RwsdhBeIrb7jZ0cgeS9iX8EmJvY+R3zY+wtq5KFJz7V t2Sxf+DX6SGAo1maC9SEFDEY6D4kuywH1UsZHFVfuCQiDnG/5QeXzdd0tD4iip3iwtTi WwbZ7KvOesrRQbTwH/PmfE6B555RdUenB3g4Dx/9EEw4+GmpAA4wYk3TtErrkH4ViZBu W1Ew== X-Forwarded-Encrypted: i=1; AHgh+Rp0SbMt6k5/F275x7AXFqA5kXsDOOqwb+Fx3ANzh089RK6KJsFCh3rSqJag/0F3B5/4czkumTVOrXXuTso=@vger.kernel.org X-Gm-Message-State: AOJu0YyeymXDRhgYkDS/KfAFVEZUl/WlAyEFGX8BAtkhSWv1Z2a+UMwP mN4Ej8Cqg74//IXcctimo6gNg+tCYteBbJIgGW+BvS1j+8i/vE+4kEH3CQLsIhG7yYx+XE2FOzI An8Ofzx5ipj/hdWzDk83T2qVDiHoqNcGJVTt0/b35yP8Ke18kMHMuZo5LBn2MxC7N4Q== X-Gm-Gg: AfdE7cn6jIQN1UTFdg4IfMI/L8O9ac4Rh8q2YRk6YV4cV+V2chOKEuVFi1si/WEov6M 6orXyBDwtKQHV98aBoRsvvDGr6yat97D4JeUUswnG3csUPMOpvB6XJo0B2mPB1ku0buUbcdZnbi +5ypt8BNfPuPdypGR2GcVUQl13UEgzv5m57N3SEwTbwJuRDalSN2Hr78Zt3rBWlv1ObFwMxz/AG avOxlkGSihKuMzVcc/sU/8VXzFduQm36sfuX0tEVE7DfMpJ/3BNfceLWQ1Bs+OdYIwjd6qxrcib 218GvjWcaZdLQISXLWxuWGe4/EVRyhTKEbnMV0bQlvTtIBR3yw2TY+oE0L1sWq88u3etzayg80C GUMyxrSZDO5mnHdk9nbj6fGEc X-Received: by 2002:a05:600c:1d1d:b0:492:40a1:1e16 with SMTP id 5b1f17b1804b1-4954a3d0d86mr27128775e9.8.1784293707916; Fri, 17 Jul 2026 06:08:27 -0700 (PDT) X-Received: by 2002:a05:600c:1d1d:b0:492:40a1:1e16 with SMTP id 5b1f17b1804b1-4954a3d0d86mr27128385e9.8.1784293707339; Fri, 17 Jul 2026 06:08:27 -0700 (PDT) Received: from redhat.com (IGLD-80-230-24-117.inter.net.il. [80.230.24.117]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4954a2a2504sm51784305e9.2.2026.07.17.06.08.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 06:08:26 -0700 (PDT) Date: Fri, 17 Jul 2026 09:08:23 -0400 From: "Michael S. Tsirkin" To: Greg Kroah-Hartman Cc: "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, carlos.bilbao.osdev@gmail.com Subject: Re: [PATCH v2 1/4] virtio-mem: validate device-reported block size Message-ID: <20260717085838-mutt-send-email-mst@kernel.org> References: <20260717014134-mutt-send-email-mst@kernel.org> <3b32a38f-0964-45b9-9529-933abedbf69b@kernel.org> <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> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2026071759-thermal-synopsis-7568@gregkh> On Fri, Jul 17, 2026 at 02:07:50PM +0200, Greg Kroah-Hartman wrote: > On Fri, Jul 17, 2026 at 06:52:46AM -0400, Michael S. Tsirkin wrote: > > On Fri, Jul 17, 2026 at 12:46:52PM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Jul 17, 2026 at 06:23:57AM -0400, Michael S. Tsirkin wrote: > > > > On Fri, Jul 17, 2026 at 12:15:09PM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Jul 17, 2026 at 06:10:41AM -0400, Michael S. Tsirkin wrote: > > > > > > On Fri, Jul 17, 2026 at 11:14:23AM +0200, Greg Kroah-Hartman wrote: > > > > > > > On Fri, Jul 17, 2026 at 04:59:32AM -0400, Michael S. Tsirkin wrote: > > > > > > > > On Fri, Jul 17, 2026 at 10:39:40AM +0200, David Hildenbrand (Arm) wrote: > > > > > > > > > On 7/17/26 07:48, Michael S. Tsirkin wrote: > > > > > > > > > > On Thu, Jul 16, 2026 at 05:59:05PM +0200, David Hildenbrand (Arm) wrote: > > > > > > > > > >>> Or do we just always trust virtio mem devices explicitly? > > > > > > > > > >> > > > > > > > > > >> It's hard for me to understand where we draw the line, really. > > > > > > > > > >> > > > > > > > > > >> But maybe MST can clarify what we care about in virtio world where the > > > > > > > > > >> hypervisor is fully in charge of the device, > > > > > > > > > > > > > > > > > > > > Generally: > > > > > > > > > > - The guest is expected to whitelist drivers (most drivers have not > > > > > > > > > > been audited). > > > > > > > > > > > > > > > > > > But even if you audited your driver, who makes sure that we consider all ways > > > > > > > > > where the device could mess with us? > > > > > > > > > > > > > > > > A lot of this is up to a correct setup. For example, make sure all > > > > > > > > filesystems are encrypted and refuse to mount unencrypted ones. > > > > > > > > > > > > > > > > > Something feels off here. > > > > > > > > > > > > > > > > > > Handling selected out-of-spec scenarios like this feels like a band-aid. Happy > > > > > > > > > to be corrected. > > > > > > > > > > > > > > > > Well Documentation/security/snp-tdx-threat-model.rst puts it like this: > > > > > > > > It is important to note > > > > > > > > that this doesn’t imply that the host or VMM are intentionally > > > > > > > > malicious, but that there exists a security value in having a small CoCo > > > > > > > > VM TCB. > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > While traditionally the host has unlimited access to guest data and can > > > > > > > > leverage this access to attack the guest, the CoCo systems mitigate such > > > > > > > > attacks by adding security features like guest data confidentiality and > > > > > > > > integrity protection. > > > > > > > > > > > > > > > > > > > > > > > > now, when we are talking about "mitigation" it is indeed becoming a bit > > > > > > > > murky. > > > > > > > > > > > > > > > > > > > > > > > > For me, a rule of thumb I came up with is that if the validation happens > > > > > > > > to also be helful for users e.g. to work around buggy devices, > > > > > > > > or maybe because we feel failing gracefully is nice because this > > > > > > > > will allow to later make use of this config and old drivers will > > > > > > > > fail but at least not panic, then it is good to include. > > > > > > > > > > > > > > Why not do what USB does? Don't trust the device until AFTER probe() > > > > > > > succeeds? All of the needed checking should happen before then, as that > > > > > > > is a "slow path" so lots of validation and the like can happen at that > > > > > > > point. > > > > > > > > > > > > > > After that, during the normal data paths, after the driver is bound, > > > > > > > trust it all you want as attempting to validate every single packet is > > > > > > > just going to be impossible. > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > greg k-h > > > > > > > > > > > > People do expect that data path validation at this point. > > > > > > > > > > Ok, so you want this patch :) > > > > > > > > > > And more, as you need to treat everything from the host as "untrusted", > > > > > and it must be "verified". > > > > > > > > Well. First it's not me) Second it's only specific configurations - > > > > for example there's no short term plan to validate filesystem code, people > > > > are expected to rely on encryption. The reasons have more to do > > > > with the available manpower than anything else. > > > > > > Sure, but again, for subsystems, you have to define your threat model as > > > the LLMs are churning against the code base and coming up with lots of > > > crazy ideas if a device should or should not be trusted and spitting out > > > patches and reports like the ones that are in the first few patches of > > > this series. > > > > > > So please, pick a model, let's document it, and go with that. I am > > > getting directly conflicting responses here. > > > > > > thanks, > > > > > > greg k-h > > > > Supposed to be this one: > > Documentation/security/snp-tdx-threat-model.rst > > > > what is missing? > > A policy decision that needs to be made. All that document does is > describe a bunch of different "threats" yet does not decide what to do > about them at all from what I can tell. That would be this section I think: The **Linux kernel CoCo VM security objectives** can be summarized as follows: it does, indeed, not go into detail about how to interact, safely, with untrusted entities. Does it really need to be spelled out? > And that's just for one subset of the CoC world, right? Is that > something that all virtio drivers need/want to care about? What is missing, and what you seem to be asking for, is an opinionated stance on which drivers we care about in this world? True. coco guys tried to annotate drivers at some point to do exactly that. this was rejected upstream from the position that this is not different from handling buggy hardware, and just to fix all drivers. so it's up to users, and I guess for virtio the answer is yes with some exceptions because we don't have a better answer right now. > So I don't see a real answer to the "does Linux trust the host to give > you good data or not" question in that file, am I missing it? > > thanks, > > greg k-h This? Note the last sentence. The **Linux CoCo VM attack surface** is any interface exposed from a CoCo guest Linux kernel towards an untrusted host that is not covered by the CoCo technology SW/HW protection. This includes any possible side-channels, as well as transient execution side channels. Examples of explicit (not side-channel) interfaces include accesses to port I/O, MMIO and DMA interfaces, access to PCI configuration space, VMM-specific hypercalls (towards Host-side VMM), access to shared memory pages, interrupts allowed to be injected into the guest kernel by the host, as well as CoCo technology-specific hypercalls, if present. Additionally, the host in a CoCo system typically controls the process of creating a CoCo guest: it has a method to load into a guest the firmware and bootloader images, the kernel image together with the kernel command line. All of this data should also be considered untrusted until its integrity and authenticity is established via attestation.