From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.219.49 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794320737; b=Jrw+1RLgkXJ38qxJen9urO6SzVW7Cp7QRm8oB8T40Ono7IT/aKez8tGjJBgFgKUA+cwt uRsEBS/qbGGoZWHTFnkpmU2Uhh7UNL3j3G4mP45VABekzRhhDo2Pvv2uYIt44XfXQO4Lg y74Q8HFP6GMMMr7DF8ubQjSMjGxPjXg5PgKTqpQcoAi5RKPuFttU/vy1HZ8Zc0l54fyx8 3YEgw7PcTvci3+ORnyLMMC3DrxrU3gmdMp2AVMh1vQYCaifG3LxXksdXXhMjV3PdufGty G6KjDhAsbnd0Enez3hJiy6PM+8xYGHaVXxcgPiOIIrgKHQ53WwFgvKi9WcU2ohNktnA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794320737; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; bh=lkAP1m7U86A6D3jq5FI3LtbBiJBALHf/XTrdqm7iRv0=; b=Y+gZC13sjzdfDw/AnujyZR19Ead6svX/0clm5jywUNK1Uw4MuT5eFMz1rpmI6rEAElc6 9QMtfBwFfxCZ8m9tZ7ac76d/B2kPqKhN1gCJFnIm9HIzVGARC+MknbwWj96NpwLC+OfNg l+/ikpxVSTtqvaU5NJ8HZvJv21pF2OYxCEBE4gykosFj4k7rGmR/EQisnVQUsOxTMhkG8 5RzkRVzaFQn0uD6nOy07crmFOUYU6XVYzm7n+vok7/t9YBbdrtSLIRZbsRXeoxPIx2JZd dO6c8apGdsv4CzVmxATzFJO05M3lhEXQHcc03dNeMIRfELHwD3C9Vssc++WDuZfIVMw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass header.d=ziepe.ca header.i=@ziepe.ca header.a=rsa-sha256 header.s=google header.b=YHCNwWvx; arc=none smtp.remote-ip=209.85.219.49 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CE21606A9BD for ; Tue, 10 Nov 2026 14:25:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 1CE21606A9BD Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.a=rsa-sha256 header.s=google header.b=YHCNwWvx Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-91ea43af0caso21046776d6.2 for ; Tue, 10 Nov 2026 06:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1794320736; x=1794925536; darn=vger.kernel.org; h=in-reply-to: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=lkAP1m7U86A6D3jq5FI3LtbBiJBALHf/XTrdqm7iRv0=; b=YHCNwWvxZ2i5OqHQ+YUqQLCC1rzv2GgovdQMVYEwKh33tRosyn7GSIJuDa41qmh/kW zi7LyeKhFQOPYEl+gUniDWgNdaawKzYRwoS7Dq0Cx9eafD18pzSWOBgk0COIE+DG118i S5bwR2UJTtx2uoqYAeHAyK/dxjo4bAnlVjVlKAp5uCve1qemG+leX9AgPW5FTMSGevza aK8L0rcHuwhC3z9DNrC7UjQwC0QG7d3DQfBuriogPZkFVd264tz+6Hml+iB06xl4HH1G y8/vRZyBHrGKwiKkupF3SKK0bECjiQV15fzHQ3Z56gBpctujXKC1iL8VZGRRSe6K9b4t 6xPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794320736; x=1794925536; h=in-reply-to: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=lkAP1m7U86A6D3jq5FI3LtbBiJBALHf/XTrdqm7iRv0=; b=h+z5CQQM88DzT+owphBOLwbQGeVr0ycH8IWNYPHsSfy5yZEVnFXfk+8Osh9/u/7OdY v1SBROfw5kZfCVzpf7Kgnuc8OX7CH2uWmDoO1t2m5u1Uq0GdYo8d3ST+0jXF9qMYtDYl A03laahwNQdFkLQlgf3jJ7CPJKLZwQh9qMsY7w/Y4dpm3udxXNA1yKXgF+6UHRwyrGJm geKKtOJ7/2SDlTznnKTZ+FN0Dqnk3BbHcg3SWJmwm0xQNEI1EzRFj2UjNL0ytSM60sXJ 4taoE1l2KSZTNa48NPM1qqh3yzVCMyclLy5SDR82wIaETb+DJdhxKovFmjBFRUV2Q/a6 2Gwg== X-Forwarded-Encrypted: i=1; AL+hErH1kx9F3RM/SSOXonbOi6v9jSUv5gunCYtpsautAo5Bq9Q8SJ6EmnJTN3Tmk+7tTqFP6WtPISAT9kNm9uE=@vger.kernel.org X-Gm-Message-State: APuU4Z86JG/bFacahoq77vRiZz0Knlmz3fvOfhX7KKjWiGgNieS0oY1q akxC19rAk+9h/tBFFpURa9tHJrUSj3csCDobpPF6yDQ0w6Y6eMAWbFbJE2ytvgZEIew= X-Gm-Gg: AYBFou3yMQvRQikPl7PBvbFW0mqMHq/T4P/GimENYkF9huoK2pII6jQNuWyaoh44e0H f3Rur+P3AWLNYQ9P6iQK5uq9s8FT6W6Z5kJvsm14eGNiC6hl3WoqCK4agdprsSOse94+v9ejjZz BCQQjp71V+sYzyZuTBEnbeHyI70MP0SZ6pbWPU2nHJVwQMZ152akdK4RPtM888V6VtxCWoO++Ej PC7sPE/LXSIrpsDtc2+MAh2PSOciKlYeHiGHHBBZPvO/0bLqlFNClGbmY2Zdydz9VMhRW2kUK+r xHm3xzXK7l+YcfJbnWi4cf3JzW9k8qUTecyjoLMHwrBMi78wVJkzq2XYDYIzjZ3IXLUeT1tfDtd MksjLt204FSmhId+eLFIaMk81s/u0V9LniReld0VIeI6+52Y13NOO+hEYihy4eyGSbtpp7YaH4m QiPcQOoDJR3gQf4aKqiBVcXzEXEeSStsRwIfK/0jLr8RJNwViLYUt4qrCwnvnZh6LFxbP5UOC/U t4BSIgA7vSJbWR99jFJHOtEyOQol7M1Uovqfuv2dlH2canefUMTM+3GtljRv2RAKX2loBHg/5Bz 22Va6H8LyZyiY3Djsqh7oWvWIdt8xe73HKn9l/0YHUcaTyLeq674F5qccPa4nJx5PgfHkfI/Fbu ipwOR6/0DqfyP X-Received: by 2002:a05:6214:5281:b0:91b:87cc:6d3e with SMTP id 6a1803df08f44-91eef628900mr47274136d6.1.1794320735682; Tue, 10 Nov 2026 06:25:35 -0800 (PST) Received: from ziepe.ca (hlfxns010zw-159-2-239-150.pppoe-dynamic.high-speed.ns.bellaliant.net. [159.2.239.150]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91ef0501c1csm21854426d6.30.2026.11.10.06.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2026 06:25:35 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1xQmn0-00000005tbF-1WYc; Tue, 10 Nov 2026 10:25:34 -0400 Date: Tue, 10 Nov 2026 10:25:34 -0400 From: Jason Gunthorpe To: Leon Romanovsky Cc: Robin Murphy , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Dmitry Torokhov , Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Johannes Berg , Jonathan Corbet , Shuah Khan , Randy Dunlap , Bjorn Helgaas , "Joerg Roedel (AMD)" , Suravee Suthikulpanit , Vasant Hegde , Will Deacon , David Woodhouse , Lu Baolu , Johan Hovold , Eric Dumazet , Marcel Holtmann , Luiz Augusto von Dentz , Nipun Gupta , Nikhil Agarwal , Pieter Jansen van Vuuren , linux-kernel@vger.kernel.org, driver-core@lists.linux.dev, linux-input@vger.kernel.org, netdev@vger.kernel.org, linux-wireless@vger.kernel.org, linux-usb@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-acpi@vger.kernel.org, linux-doc@vger.kernel.org, linux-pci@vger.kernel.org, iommu@lists.linux.dev Subject: Re: [PATCH v2 18/19] PCI: Replace untrusted state with device trust Message-ID: <20261110142534.GY663069@ziepe.ca> References: <20261109-device-trust-core-v2-0-3b12d9a9f861@nvidia.com> <20261109-device-trust-core-v2-18-3b12d9a9f861@nvidia.com> <20261110122237.GG8635@unreal> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261110122237.GG8635@unreal> On Tue, Nov 10, 2026 at 02:22:37PM +0200, Leon Romanovsky wrote: > On Mon, Nov 09, 2026 at 01:53:02PM +0000, Robin Murphy wrote: > > On 09/11/2026 7:33 am, Leon Romanovsky wrote: > > [...] > > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > > > index b486b8bbd1fcd..8be2a246d4903 100644 > > > --- a/drivers/iommu/iommu.c > > > +++ b/drivers/iommu/iommu.c > > > @@ -1879,7 +1879,7 @@ static int iommu_get_def_domain_type(struct iommu_group *group, > > > static int iommu_get_default_domain_type(struct iommu_group *group, > > > int target_type) > > > { > > > - struct device *untrusted = NULL; > > > + struct device *restricted = NULL; > > > struct group_device *gdev; > > > int driver_type = 0; > > > @@ -1901,14 +1901,15 @@ static int iommu_get_default_domain_type(struct iommu_group *group, > > > driver_type = iommu_get_def_domain_type(group, gdev->dev, > > > driver_type); > > > - if (dev_is_pci(gdev->dev) && to_pci_dev(gdev->dev)->untrusted) { > > > + if (dev_is_pci(gdev->dev) && > > > + pci_dev_default_is_restricted(to_pci_dev(gdev->dev))) { > > > > I think this should be the generic device_is_adversarial(gdev->dev) now - in > > fact probably all the dev_is_pci()/to_pci_dev() stanzas aren't conceptually > > PCI-specific, just an artefact of the current "untrusted" flag being so. > > I wanted to do the same, but iommu_get_default_domain_type() may be called > before the PCI device's trust level has been set. At that point, we are > still in "disabled" mode, whereas device_is_adversarial() checks for > "adversarial" mode. > > The below is from AI, I asked to present me the path for that: > -------------------------------------------------------------------------------- > For a newly discovered PCI device with an available IOMMU and a new IOMMU group: > pci_scan_single_device() > pci_device_add() > device_add() > bus_notify(dev, BUS_NOTIFY_ADD_DEVICE) > blocking_notifier_call_chain() > notifier_call_chain() > iommu_bus_notifier() > iommu_probe_device(dev) > __iommu_probe_device(dev, NULL) > iommu_setup_default_domain(group, 0) > iommu_get_default_domain_type(group, 0) > > For a device whose initial policy is adversary, its state during that call is: > dev->trust_policy = DEVICE_TRUST_POLICY_ADVERSARY > dev->trust_level = DEVICE_TRUST_DISABLED > dev->trust_committed_level = DEVICE_TRUST_DISABLED > dev->driver = NULL > > device_is_adversarial(dev) = false > > The active level changes later, during binding: > really_probe() > device_trust_prepare() > __device_trust_prepare() > WRITE_ONCE(dev->trust_level, DEVICE_TRUST_ADVERSARY) > dev->bus->dma_configure() > call_driver_probe() The ordering here is wrong, this is a consequence of splitting this into different series. I don't think we need to fix it in this series, but as a followup. For now I would aim to make 'no functional change' and still follow the ACPI selection during default domain creation. The long term goal is to detect that the trust level is disabled during iommu_probe_device() (ie we are running in a secure booting mode), attach the device to BLOCKED (which should be a NOP) and defer allocating the default domain. This would preserve the DRTM iommu & ATS blocked behavior through until driver binding, giving userspace a chance to do an attestation, turn on link ide and so on before exposing the system to DMA from the device. Once userspace sets the trust level and binds a driver then we can allocate a default domain using the user set trust level and avoid the above problem. For the CC VM use case today there won't be a vIOMMU, and there is an indepenent control for DMA ENABLE in the TSM driver so this doesn't matter right now for CC. Probably put this detail in the commit message Jason