From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793893547; b=blZ8EntqAG2AAdKtM5z4kj1AbeUCAh6gVRbnx5Do/8ZwANky1L11bIfoCL85hw8Jq9Kf 9VHcTRToGwr8sNJRNGR06XNDzFkZFvKdWrYrd+AUywf45gWCpWkQSiV3YXoEx8GOcJJgv qrBTsLvJ5ATe/ciaoyH7qUawXYsNjhoq7cCrnDOn+kCNtZOsFfvI7Jt9JExC20twkInbT bSAeYH2Tv5ezlRDDkuKQ41EVkiN3eGNMWOMRjLZsi/b4dz1/YseIm49qJLSJGQlPYuz88 fMz+BYyXIndJSJOCdx82EqqrDPzHCnnWQ3LMtrzAMZJ7ni9GQrayv8qbzJHBeHhATVQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793893547; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=r8nVCxRr/caFl0VvSs+H/hiL0jp8irU+aVqqr+Vt2CA=; b=5rCkrfhqEUdRWyn1iIXmwQgrtgT4LbKFpJ60UfX6syAKo/04RngVzk06VfhkSXDuB7ry wPhnmbLnNwB1Cw5cHK0gGR34q01sCk+cYJhkmQ+a9EMxOhBoYg1hMxaJop1u5SaaHa2RR 8bsfmYlx9gvnM9cfVtTrzMyl9SQVrdPpwPG4x8aANRxEme7mH/hqPGZLgosAjTL6fsOoK Vc/VrXoNGN3k87v96D1Cu6/xiC8bgmrYPzT9u4JDVLMhlU8bJ33bmzBjE2wuO0auVT4cB nviGlB66VcV/5eqlByb5AxZmDQUpnxn7/oDVGfOKVmUdyMPQanGJVaG7vBUemXgWIgg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=meaN+OhO; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BD15606A33E; Thu, 5 Nov 2026 15:45:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=meaN+OhO Received: by smtp.kernel.org (Postfix) with ESMTPSA id B873B1F00A20; Thu, 5 Nov 2026 15:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793893546; bh=r8nVCxRr/caFl0VvSs+H/hiL0jp8irU+aVqqr+Vt2CA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=meaN+OhOvNMzUiSpkbxD6EVBd0OEbPvrP1jGl/qwyY0z+wE5jdB+PgyFec94YPgqy S4EvLxBoXRhzFxyRbbnsnlivK8Ca0AftS8DmC7SltX8mquIL1iPg+W2fY6Ru9PmF2d q5KtVgSP6lw2tQlIVqFt0mj9cI6SeYB7128uF+1w= Date: Thu, 5 Nov 2026 10:45:44 -0500 From: Greg Kroah-Hartman To: Robin Murphy Cc: Leon Romanovsky , "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, Jason Gunthorpe Subject: Re: [PATCH 10/17] driver core: Expose device trust authorization through sysfs Message-ID: <2026110540-blazing-wifi-5082@gregkh> References: <20261105-device-trust-core-v1-0-1e536825b4eb@nvidia.com> <20261105-device-trust-core-v1-10-1e536825b4eb@nvidia.com> <2026110514-bunkhouse-handset-6a3a@gregkh> <20261105132729.GB8298@unreal> <2026110535-engulf-precut-cf10@gregkh> <9d896ebb-6892-4cac-a7c5-41def47f0be0@arm.com> <2026110556-sculpture-immovable-ca8b@gregkh> <0438755d-dc1f-4c8c-b274-5555ef3d49a3@arm.com> X-Mailing-List: linux-input@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: <0438755d-dc1f-4c8c-b274-5555ef3d49a3@arm.com> On Thu, Nov 05, 2026 at 02:26:39PM +0000, Robin Murphy wrote: > On 2026-11-05 2:03 pm, Greg Kroah-Hartman wrote: > > On Thu, Nov 05, 2026 at 01:59:20PM +0000, Robin Murphy wrote: > > > On 2026-11-05 1:40 pm, Greg Kroah-Hartman wrote: > > > > On Thu, Nov 05, 2026 at 03:27:29PM +0200, Leon Romanovsky wrote: > > > > > On Thu, Nov 05, 2026 at 08:10:14AM -0500, Greg Kroah-Hartman wrote: > > > > > > On Thu, Nov 05, 2026 at 01:42:23PM +0200, Leon Romanovsky wrote: > > > > > > > From: Leon Romanovsky > > > > > > > > > > > > > > An initrd must authorize a disabled device after attestation even if a > > > > > > > built-in driver already attempted to probe it. > > > > > > > > > > > > > > Expose requested trust_policy and read-only active trust. Allow explicit > > > > > > > disabled policy to advance once to adversary or full, fixing that decision > > > > > > > immediately. Reject later policy changes, including for a device claimed > > > > > > > before registration, while allowing same-value writes on live devices. > > > > > > > Keep initial unrestricted selection separate from explicit authorization > > > > > > > and bind-time commitment. Serialize writes with probing under the device > > > > > > > lock. Include the attributes in device ownership changes. > > > > > > > > > > > > > > Signed-off-by: Leon Romanovsky > > > > > > > --- > > > > > > > Documentation/ABI/testing/sysfs-devices-trust | 51 +++++++++++++ > > > > > > > MAINTAINERS | 1 + > > > > > > > drivers/base/base.h | 6 ++ > > > > > > > drivers/base/core.c | 15 +++- > > > > > > > drivers/base/trust.c | 102 ++++++++++++++++++++++++++ > > > > > > > 5 files changed, 174 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-devices-trust b/Documentation/ABI/testing/sysfs-devices-trust > > > > > > > new file mode 100644 > > > > > > > index 0000000000000..97e07a174769c > > > > > > > --- /dev/null > > > > > > > +++ b/Documentation/ABI/testing/sysfs-devices-trust > > > > > > > @@ -0,0 +1,51 @@ > > > > > > > +What: /sys/devices/.../trust > > > > > > > +Date: September 2026 > > > > > > > +Contact: driver-core@lists.linux.dev > > > > > > > +Description: > > > > > > > + (RO) The active trust level for the device. The values are > > > > > > > + "disabled", "adversary", and "full". Driver core resolves > > > > > > > + the level before DMA configuration and probe, and retains it > > > > > > > + through removal and DMA cleanup. Outside a bind transaction > > > > > > > + the level is "disabled". This does not imply that policy is > > > > > > > + writable or that the device has never operated. > > > > > > > + > > > > > > > +What: /sys/devices/.../trust_policy > > > > > > > +Date: September 2026 > > > > > > > +Contact: driver-core@lists.linux.dev > > > > > > > +Description: > > > > > > > + (RW) The requested trust policy for the device. The initial > > > > > > > + value may be selected by the bus before the device is > > > > > > > + registered; otherwise it is "default". The policy is resolved > > > > > > > + to an active trust level before the device is probed. > > > > > > > + > > > > > > > + The values are "default", "disabled", "adversary", and > > > > > > > + "full". "default" lets the bus select the active trust level. > > > > > > > + "disabled" prevents a functional driver from binding. > > > > > > > + "adversary" requests operation with the restrictions that the > > > > > > > + bus and DMA layers can enforce for a potentially malicious > > > > > > > + device; it does not isolate DMA by itself. "full" requests > > > > > > > + normal operation. > > > > > > > + > > > > > > > + Before an operating level is committed, policy may change > > > > > > > + freely until "disabled" is selected. Explicit "disabled" > > > > > > > + blocks binding while allowing a later write of "adversary" or > > > > > > > + "full". Repeated rejected probes preserve this opportunity. > > > > > > > + Authorization immediately fixes the requested policy. > > > > > > > + Returning to "default" or "disabled", or selecting another > > > > > > > + mode, fails. > > > > > > > + > > > > > > > + Successful resolution to an allowed level commits policy > > > > > > > + and operating level before driver or DMA setup. Both remain > > > > > > > + fixed for the device object's lifetime, including through > > > > > > > + failed or deferred probes, unbind, reset, and driver reload. > > > > > > > + Later binds must resolve to the same level, including when > > > > > > > + the policy is "default". A resolver error or disabled result > > > > > > > + before commitment leaves the policy's writability unchanged. > > > > > > > > > > > > I understand you are aproaching this from a PCI point-of-view, but many > > > > > > busses do not care or have DMA at all, and need to actually talk to the > > > > > > device before being able to even "add" it to the kernel. So you are > > > > > > making a driver core-specific policy based on mentioning DMA here, when > > > > > > really that should only be a bus-specific thing, right? Some busses > > > > > > might require DMA to happen (i.e. USB needs their host controllers to > > > > > > use DMA to even talk to the device at all). > > > > > > > > > > > > So can this be written to be more vague and generic and then put the > > > > > > specifics in the bus-specific portion? > > > > > > > > > > Yes, of course. The main point is that drivers must not communicate with > > > > > or configure hardware before attestation is approved. DMA is the PCI > > > > > way to communicate with hardware. > > > > > > > > That's a very vague statement of "must not communicate with". Busses > > > > HAVE to talk to the device to determine what the device even is before > > > > it can add it to its internal bus list. That's just how the hardware > > > > works, you can't say "no talking at all" otherwise that means that you > > > > never even know if a device is there (and for some busses, you'll miss > > > > the device entirely as they can only be found when the "host controller" > > > > tells the kernel that a device showed up, not later by manually > > > > scanning.) > > > > > > > > Think about reading PCI device ids, or USB configuration information, > > > > that's a bus-core thing. Are you really thinking that non of this can > > > > be read from a device under this "policy"? > > > > > > Yup, and that's true even in the PCI TDISP case - there's a major amount of > > > "communication" and "configuration" involved in that. The principle which > > > should (hopefully) generalise is that a bus/host controller driver can > > > always interrogate its child device to perform whatever attestation and > > > general configuration is appropriate, but we won't hand off any _control_ of > > > that device to a specific device driver (nor enable potentially-impactful > > > bus-level features like DMA, interrupts, etc. if relevant) without the > > > requisite agreement between the bus code and the user. > > > > I agree, that's fine, the bus core should always be able to talk to the > > device, the "barrier" is where the device is handed to a driver for that > > bus. That's what I'm trying to say here, DMA is often needed before > > that can ever happen, so no claims of "no dma is happening" should be > > here. > > For the case of USB and co. it's also still fine - just perhaps wants some > clearer wording - since the endpoint itself is not performing DMA > operations. It might send some message which causes the host controller > device to DMA to/from a buffer owned by the host controller driver, but > that's perfectly OK since the host controller itself is not on its own bus, > and must have already been accepted by the PCI/platform/whatever code to get > to that point. > > Now if we had some bonkers kind of bus where the only way to identify an > endpoint was to give it DMA addresses to have it read a command descriptor > and write out its own data directly, then indeed there would be little hope > of being able to enforce much of a trust model for that... Look at how USB typec code handles many parts of the device discovery process. Lots of data is read and written for loads of different things that the device provides and the kernel has to "trust" to be correct. It's very very complex and DMA and other buffers and resources are quite involved here. We have tried to "harden" most of these paths now, but odds are we haven't found them all... thanks, greg k-h