mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Vasant Hegde <vasant.hegde@amd.com>,
	Will Deacon <will@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Johan Hovold <johan@kernel.org>,
	Eric Dumazet <edumazet@kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	Nipun Gupta <nipun.gupta@amd.com>,
	Nikhil Agarwal <nikhil.agarwal@amd.com>,
	Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>,
	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, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH v2 18/19] PCI: Replace untrusted state with device trust
Date: Tue, 10 Nov 2026 14:22:37 +0200	[thread overview]
Message-ID: <20261110122237.GG8635@unreal> (raw)
In-Reply-To: <d0999161-3b27-4c3b-9d66-1d117c4836fd@arm.com>

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()

> 
> >   			/*
> > -			 * No ARM32 using systems will set untrusted, it cannot
> > -			 * work.
> > +			 * No ARM32 using systems select a restricted trust
> > +			 * policy; it cannot work.
> >   			 */
> >   			if (WARN_ON(IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)))
> >   				return -1;
> > -			untrusted = gdev->dev;
> > +			restricted = gdev->dev;
> >   		}
> >   	}
> [...]
> > @@ -616,6 +608,28 @@ static inline struct pci_dev *to_pci_dev(const struct device *dev)
> >   {
> >   	return container_of(dev, struct pci_dev, dev);
> >   }
> > +
> > +static inline bool
> > +pci_dev_default_is_restricted(const struct pci_dev *pdev)
> > +{
> > +	enum device_trust_policy policy = READ_ONCE(pdev->dev.trust_policy);
> > +
> > +	return policy == DEVICE_TRUST_POLICY_DISABLED ||
> > +	       policy == DEVICE_TRUST_POLICY_ADVERSARY;
> > +}
> 
> Unless I've wildly misunderstood, I'm not sure this is right - if the user
> has set DEVICE_TRUST_POLICY_DISABLED to explicitly override the bus-default
> behaviour, but that leads to the IOMMU layer special-casing all PCI devices
> as adversarial and thus force-*enabling* all their trust-model restrictions,
> isn't that pretty much the complete opposite of what was asked for?

We have two levels: policy - that describes the default of all devices
for that bus. level - actual decision on how that device is going to be
operated.

"Disabled" prevents driver probing until the device is authorized,
"Adversary" permits probing and requests the available protections
for operating an untrusted device.

Both need conservative initial IOMMU setup: a disabled device may later
be authorized as adversary, and authorization does not rebuild its IOMMU
domain.

Thanks

> 
> Thanks,
> Robin.
> 
> > +
> > +static inline bool pci_dev_ats_permitted(const struct pci_dev *pdev)
> > +{
> > +	enum device_trust_level level = device_get_trust_level(&pdev->dev);
> > +	enum device_trust_policy policy = READ_ONCE(pdev->dev.trust_policy);
> > +
> > +	if (level == DEVICE_TRUST_DISABLED)
> > +		return policy != DEVICE_TRUST_POLICY_ADVERSARY &&
> > +		       policy != DEVICE_TRUST_POLICY_DISABLED;
> > +
> > +	return level == DEVICE_TRUST_FULL;
> > +}
> > +
> >   #define for_each_pci_dev(d) while ((d = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, d)) != NULL)
> >   #define for_each_pci_dev_reverse(d) \
> >   	while ((d = pci_get_device_reverse(PCI_ANY_ID, PCI_ANY_ID, d)) != NULL)
> > 
> 

  reply	other threads:[~2026-11-10 12:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  7:33 [PATCH v2 00/19] driver core: Authorize device trust before driver binding Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 01/19] Input: gameport - attach manual drivers through the driver core Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 02/19] wifi: mac80211_hwsim: lock device for manual driver binding Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 03/19] USB: Lock registered interfaces during " Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 04/19] USB: Release interface claims refused during registration Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 05/19] PNP: Attach card devices through the driver core Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 06/19] cdx: Propagate DMA configuration errors Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 07/19] driver core: Report deferred probes through sysfs drivers_probe Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 08/19] driver core: Add a compatibility API for manual driver attachment Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 09/19] Input: serio - use the compatibility driver attachment API Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 10/19] net: phy: Use " Leon Romanovsky
2026-11-09 13:45   ` Andrew Lunn
2026-11-10  7:39     ` Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 11/19] driver core: Introduce a generic device trust level Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 12/19] driver core: Expose device trust authorization interfaces Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 13/19] driver core: Accept device trust policy on the kernel command line Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 14/19] driver core: Accept device trust policy by driver name Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 15/19] driver core: Expose committed device trust level Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 16/19] driver core: Cover trust authorization and binding with KUnit Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 17/19] driver core: Document trust admission and initrd authorization Leon Romanovsky
2026-11-09  7:33 ` [PATCH v2 18/19] PCI: Replace untrusted state with device trust Leon Romanovsky
2026-11-09 13:53   ` Robin Murphy
2026-11-10 12:22     ` Leon Romanovsky [this message]
2026-11-10 14:25       ` Jason Gunthorpe
2026-11-09  7:33 ` [PATCH v2 19/19] USB: Authorize devices and interfaces through " Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261110122237.GG8635@unreal \
    --to=leon@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=dwmw2@infradead.org \
    --cc=edumazet@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=johan@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=joro@8bytes.org \
    --cc=kuba@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikhil.agarwal@amd.com \
    --cc=nipun.gupta@amd.com \
    --cc=pabeni@redhat.com \
    --cc=pieter.jansen-van-vuuren@amd.com \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=skhan@linuxfoundation.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®