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 52C253DDB1B for ; Fri, 17 Jul 2026 10:24:05 +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=1784283849; cv=none; b=uwoRdo3sg4xGBhwd1aHA4zk73Vqbwtxc0CWDmSNUu0FaCx3z5NDQ+ZLBQXcGQSYuNn4OrMd6WcyY6br6oBrAW+h3u/l7OHKmeSxGEBihSSuWEOZljtUMx/j4Y2OKdSGG8GdIbhH2lGtRXcI76R7ZcS6+SvyNx6ExesVSDCGfWp4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784283849; c=relaxed/simple; bh=dFnwQxSzZV5PRkOGla0gIrk3G+di+qRW3UiXe3gSizI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Tty8yhvLKZfl4mLNkhZ4VkBs6/kPJr8DcSh4Yr10QV0KGMhyXOwhZjXaAGwHUBPhHgKye7ykxiKYO+dRQ7u70+Nx0jhgQKjuy24qeSFmDT6P3pMOqe5Y33sbFnVH8+AXu1VDTDGg/cevtn3wQQFgj75wwxG/1kHT/naIXxkN9Xo= 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=VDBDHMqZ; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=tRYPpJPz; 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="VDBDHMqZ"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="tRYPpJPz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784283844; 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=rcifcBgeFrOFIjK2y9k5VWrTOWRUYUBUyPh+odVYasU=; b=VDBDHMqZa2j5A4X3yZXAUpe9cCSo1yN5Th4/bJF/ju6jFfX2cSTUv+zjR20VdRIM8piu3e whsy1ncnz9mqa3w6mf8qqk2HbAkf0G6X8Ooa3RBlALMCwqosVp/8/+GMdwBe0Qw9nzmxiP jmlCrgiIpx6tlWBMEeqiOH0vqSQ764Q= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-86-o1sl1ZcpM1StKmuprAT4QQ-1; Fri, 17 Jul 2026 06:24:03 -0400 X-MC-Unique: o1sl1ZcpM1StKmuprAT4QQ-1 X-Mimecast-MFC-AGG-ID: o1sl1ZcpM1StKmuprAT4QQ_1784283842 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4729d2a64efso841615f8f.0 for ; Fri, 17 Jul 2026 03:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1784283842; x=1784888642; 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=rcifcBgeFrOFIjK2y9k5VWrTOWRUYUBUyPh+odVYasU=; b=tRYPpJPzw4aS4gaKvpqv5Tm2NP75WqX7RsIX0GrOFVOZdqpcooXcpm/KySOIfnemwf DZ/ga2qVJeJOSaR14501c57sJ9e9++enQzABG7cVVdl6/5ebOg6MKMGthFn5dFYLYj49 k9cKaGQOSeM0vdwarqBgu87QalORo/z07pg3JpN3FdRA/XTVamQuUl1SvC8jdPKRG/u8 fcHOnYpra/B/uoaZjicOMaWSISY+SCY5xwAzIMvccC6a9fihHTkhuKkJGHD5zeuPkRSv rOBHiAxiDyO8wif4cseWAWfpMCZpJpr+KZoGgJnPBQsSPPeBz6dIE/tEj2M0J2ZimvhP sP3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784283842; x=1784888642; 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=rcifcBgeFrOFIjK2y9k5VWrTOWRUYUBUyPh+odVYasU=; b=dvj4QZq3OtsjQaj1BHvsRv8/dmoR4arWw3aWWXrCg23FXiERvAG1P02PvJ0UzIXL33 6RRhs8JKgDum1XeoRo77uZ9DfhH/pD59BZemR1ZF8xoXrk6x40wVmqCVyJP6dyLicNNj I2whyqyoi2WZQcll1dxbpZtGJjK+GgkcoypPGMApzhQVQ5RSiqPrZHz4IaPCccaveE0z i+FqobqZx6JjE8z2kcYk8+wI4IIDzVo2IEfB0pV8i5f/LbXSbobXtiCAyCOSJm/29ExK 37KGD14GWxcV50M9YnaVlT5445hQu6bQRmJEWDOOJctlHH2D7e/F7yoKCdxIqDTwEyKi fHGQ== X-Forwarded-Encrypted: i=1; AHgh+RqDI43c9Jqq1QSKO8jbkZkYXErJ+Jiejg9DtDj6mmvI9wqkm4LeY8lyKzRQtTZPSG2X5sjn7N39oVE9v74=@vger.kernel.org X-Gm-Message-State: AOJu0YyPQ8MGIJR+NBGzrq4bo2idsDzJ9gFFrfVbLRQ5bKWM3xYmX993 6WOxqaEenqkVQ2CVf2MGZe7jrsBJiws11PmxUD2zQpC1Q8EE67vjM3nCz70/gSn0QgTb7kx4Ioj 47RIbPu0yBVo3lFtDSLVXka1O/XPzxSE+LKm4PikBRSFd3WBphB/Un7GFmkTceu6RYg== X-Gm-Gg: AfdE7cmrlDKkzZUafc+kDTEijNeXxFMs8TsKLD5LcS8BG03eRVIfnV+0IIdWLvygQi/ zy9DKVmtawMok1uuF0qWM7CGaZuxtpyfKATICeQVX7KT9va6890Tf74f7lUR3qCLUDWmUYILD78 PjimnmH6aPUI8h/YKmWE/HUrqIBMtoXYfUJRC7d/5910yppVP1Hhpz6F9g98yYs6aNCK3Upwgay itNDUjOyKF+Sp7exFO4xsFj43KbTrlGjLno41FaGvubcRkzvJ0g58sqitT8VyxYKERrNmMmgrG9 +COfe/Ejr6I8T5zPewso6ks++/6hLFUoHfIwb0p5wu/+TcKkasIWsaWc8Aoyt0S5A/p6uQrSm/F d2Ujs6Jm/kI3pbx+gxjauePh3 X-Received: by 2002:a05:6000:1885:b0:47d:f6a5:1fd6 with SMTP id ffacd0b85a97d-47f623f189bmr2419391f8f.26.1784283841615; Fri, 17 Jul 2026 03:24:01 -0700 (PDT) X-Received: by 2002:a05:6000:1885:b0:47d:f6a5:1fd6 with SMTP id ffacd0b85a97d-47f623f189bmr2419319f8f.26.1784283840923; Fri, 17 Jul 2026 03:24:00 -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 ffacd0b85a97d-47f63ec66ebsm2653245f8f.21.2026.07.17.03.23.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 03:24:00 -0700 (PDT) Date: Fri, 17 Jul 2026 06:23:57 -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: <20260717061901-mutt-send-email-mst@kernel.org> References: <20260715164139.40957-1-harimishal1@gmail.com> <2026071635-relive-flogging-2a81@gregkh> <4dda47ba-534a-4297-a25e-0d63d9167033@kernel.org> <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> 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: <2026071757-grout-composer-165d@gregkh> 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. > Much like the proposed Rust patches we keep > slowly working on, which would make this much more obvious as to exactly > what needs to be verified, and where it happens. > > thanks, > > greg k-h Or much like networking, except it's an old robust codebase. -- MST