Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@amd.com>
To: Dan Williams <djbw@kernel.org>, linux-coco@lists.linux.dev
Cc: linux-pci@vger.kernel.org, driver-core@lists.linux.dev,
	ankita@nvidia.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATCH 13/15] PCI, device core: Add private memory access for DEVICE_TRUST_TCB
Date: Thu, 9 Jul 2026 17:38:14 +1000	[thread overview]
Message-ID: <39809986-74dd-476f-ba61-a0a9187862d5@amd.com> (raw)
In-Reply-To: <f8b5b966-ea36-4b4a-a9f5-58a20855a6fb@amd.com>



On 9/7/26 16:32, Alexey Kardashevskiy wrote:
> On 6/7/26 08:08, Dan Williams wrote:
>> A device that wants to access private memory needs to have its trust
>> elevated to DEVICE_TRUST_TCB. That trust is established either at compile
>> time (unlikely), the bus knows the device is within the TCB to start (some
>> paravisor setups), or the device is dynamically added to the TCB in
>> coordination with a TSM driver (primary TDISP use case) and the trust is
>> elevated by driver match.
>>
>> When a PCI device is associated with a TSM for security services the low
>> level TSM driver in the CC VM has the opportunity validate DMA access.
>> That validation happens at ->dma_configure() time when the device attaches
>> to a driver. The TSM driver is responsible for proving to the platform TSM
>> that the VM is enabling DMA with respect to the most recently generated
>> evidence. If that fails, driver attach fails.
>>
>> When a PCI device is not associated with a TSM provider for security
>> services, but the device is trusted there are 3 options.
>>
>> 1/ Arch requires all DMA enable events to be acked by TSM driver
>>
>> 2/ Arch does not require, but admin policy is responsible for knowing which
>>     devices need TSM coordination to become active within the TCB.
>>
>> 3/ Device is approved by a paravisor to operate within the TCB, no TSM
>>     coordination required.
>>
>> In cases 2 and 3 if the device needed TSM driver coordination, but the TSM
>> driver or association to the device is missing, it triggers hardware
>> errors. Those errors are a configuration error that the kernel does not
>> actively prevent.
>>
>> Architectures still need to fixup force_dma_unencrypted() to call
>> device_tcb_trusted() to tell the DMA layer that TCB access is granted.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>> Cc: Danilo Krummrich <dakr@kernel.org>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: Dexuan Cui <decui@microsoft.com>
>> Signed-off-by: Dan Williams <djbw@kernel.org>
>> ---
>>   drivers/base/Kconfig         | 19 ++++++++++++++++++-
>>   include/linux/device/trust.h |  4 ++++
>>   drivers/base/trust.c         |  8 ++++++++
>>   drivers/pci/pci-driver.c     | 25 ++++++++++++++++---------
>>   4 files changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
>> index a4233bdf9804..3597b39ee0e3 100644
>> --- a/drivers/base/Kconfig
>> +++ b/drivers/base/Kconfig
>> @@ -304,7 +304,17 @@ config DEVICE_TRUST_AUTO
>>       help
>>         Typical historical driver model, devices eagerly attempt to attach to
>>         a driver and deploy all available mechanisms to allow performant
>> -      direct memory access.
>> +      direct memory access. This trust level does not include TCB privileges.
>> +
>> +config DEVICE_TRUST_TCB
>> +    bool "TCB"
>> +    depends on EXPERT
>> +    help
>> +      Devices are assumed to be within the Trusted Compute Boundary (TCB)
>> +      with access to private TCB resources by default. This requires buses
>> +      to have trust awareness and opt devices out of private operation,
>> +      otherwise TCB integrity may fail the device's access or escalate to
>> +      terminating the execution context (kill the CC VM).
>>   endchoice
>> @@ -330,6 +340,13 @@ config BUILTIN_DEVICE_TRUST_ADVERSARY
>>       help
>>         Deploy mitigations in the IOMMU layer and driver to limit access.
>> +config BUILTIN_DEVICE_TRUST_TCB
>> +    bool "TCB"
>> +    depends on EXPERT
>> +    help
>> +      Devices bound by built-in drivers are assumed to be within the
>> +      Trusted Compute Boundary with access to private/encrypted memory.
>> +
>>   endchoice
>>   endmenu
>> diff --git a/include/linux/device/trust.h b/include/linux/device/trust.h
>> index 283d3196e5e6..24951f5c56ba 100644
>> --- a/include/linux/device/trust.h
>> +++ b/include/linux/device/trust.h
>> @@ -13,6 +13,7 @@
>>    * @DEVICE_TRUST_NONE: Blocked when idle, cannot bind
>>    * @DEVICE_TRUST_ADVERSARY: Blocked when idle, constrained when active.
>>    * @DEVICE_TRUST_AUTO: All typical privileges granted
>> + * @DEVICE_TRUST_TCB: AUTO privileges + private/encrypted memory access
>>    *
>>    * Devices flagged as adversarial are the ones that can potentially
>>    * execute DMA attacks and similar. They are typically connected through
>> @@ -25,11 +26,13 @@ enum device_trust {
>>       DEVICE_TRUST_NONE,
>>       DEVICE_TRUST_ADVERSARY,
>>       DEVICE_TRUST_AUTO,
>> +    DEVICE_TRUST_TCB,
>>   };
>>   #define DEVICE_DEFAULT_TRUST \
>>       (IS_ENABLED(CONFIG_DEVICE_TRUST_NONE)      ? DEVICE_TRUST_NONE      : \
>>        IS_ENABLED(CONFIG_DEVICE_TRUST_ADVERSARY) ? DEVICE_TRUST_ADVERSARY : \
>> +     IS_ENABLED(CONFIG_DEVICE_TRUST_TCB)       ? DEVICE_TRUST_TCB       : \
>>        DEVICE_TRUST_AUTO)
>>   struct device;
>> @@ -37,6 +40,7 @@ struct device_driver;
>>   #ifdef CONFIG_DEVICE_TRUST
>>   bool device_untrusted(struct device *dev);
>> +bool device_tcb_trusted(struct device *dev);
>>   void module_driver_trust(struct module *mod, const char *val);
>>   void module_driver_trust_init(struct module *mod, bool require_trust);
>>   #else
>> diff --git a/drivers/base/trust.c b/drivers/base/trust.c
>> index 8efbe5c51250..21d374affbba 100644
>> --- a/drivers/base/trust.c
>> +++ b/drivers/base/trust.c
>> @@ -23,11 +23,18 @@ bool device_untrusted(struct device *dev)
>>       return dev->bus_trust && dev->bus_trust <= DEVICE_TRUST_ADVERSARY;
>>   }
>> +bool device_tcb_trusted(struct device *dev)
>> +{
>> +    return dev->p->trust >= DEVICE_TRUST_TCB;
>> +}
>> +
>>   /* Driver trust policy requires modules, builtin drivers always attach */
>>   static enum device_trust builtin_driver_trust(void)
>>   {
>>       if (IS_ENABLED(CONFIG_BUILTIN_DEVICE_TRUST_ADVERSARY))
>>           return DEVICE_TRUST_ADVERSARY;
>> +    else if (IS_ENABLED(CONFIG_BUILTIN_DEVICE_TRUST_TCB))
>> +        return DEVICE_TRUST_TCB;
> 
> 
> No plan to override this via the kernel cmdline?


Just tried - my test guest kernel has everything built-in. Since there is no module parameter - I did CONFIG_BUILTIN_DEVICE_TRUST_TCB=y. But now every driver gets this level, including virtio, which cannot ever be "TCB" (as anything emulated by QEMU). Thanks,


-- 
Alexey


  reply	other threads:[~2026-07-09  7:38 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-05 22:08 [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Dan Williams
2026-07-05 22:08 ` [PATCH 01/15] netlink: specs: Introduce multi-message blobs for SPDM Dan Williams
2026-07-08 11:13   ` Donald Hunter
2026-07-11  1:43     ` Dan Williams (nvidia)
2026-07-08 13:23   ` Donald Hunter
2026-07-05 22:08 ` [PATCH 02/15] tools: ynl: Teach pyynl to handle blobs Dan Williams
2026-07-08 13:48   ` Donald Hunter
2026-07-05 22:08 ` [PATCH 03/15] tools: ynl: Teach ynl_gen_c to validate and dump 'blob' attributes Dan Williams
2026-07-05 22:08 ` [PATCH 04/15] device core: Introduce "device evidence" over netlink Dan Williams
2026-07-08 13:22   ` Donald Hunter
2026-07-05 22:08 ` [PATCH 05/15] device core: Add "device evidence" 'validate' command Dan Williams
2026-07-05 22:08 ` [PATCH 06/15] PCI/TSM: Add device evidence support Dan Williams
2026-07-08  5:00   ` Alexey Kardashevskiy
2026-07-08 18:25     ` Dan Williams (nvidia)
2026-07-05 22:08 ` [PATCH 07/15] modules: Document the global async_probe parameter Dan Williams
2026-07-05 22:08 ` [PATCH 08/15] device core: Initial device trust infrastructure Dan Williams
2026-07-06 13:45   ` Jason Gunthorpe
2026-07-05 22:08 ` [PATCH 09/15] PCI, device core: Move "untrusted" concept to DEVICE_TRUST_ADVERSARY Dan Williams
2026-07-06 13:49   ` Jason Gunthorpe
2026-07-07 13:04   ` Robin Murphy
2026-07-05 22:08 ` [PATCH 10/15] PCI/TSM: Add device interface security LOCKED support Dan Williams
2026-07-05 22:08 ` [PATCH 11/15] PCI/TSM: Add device interface security RUN support Dan Williams
2026-07-05 22:08 ` [PATCH 12/15] PCI/TSM: Add device interface security DMA enable/disable Dan Williams
2026-07-05 22:08 ` [PATCH 13/15] PCI, device core: Add private memory access for DEVICE_TRUST_TCB Dan Williams
2026-07-06 12:42   ` Aneesh Kumar K.V
2026-07-08 18:06     ` Dan Williams (nvidia)
2026-07-08 18:10       ` Aneesh Kumar K.V
2026-07-09  6:32   ` Alexey Kardashevskiy
2026-07-09  7:38     ` Alexey Kardashevskiy [this message]
2026-07-05 22:08 ` [PATCH 14/15] PCI/TSM: Create MMIO descriptors via TDISP Report Dan Williams
2026-07-08  9:49   ` Alexey Kardashevskiy
2026-07-05 22:08 ` [PATCH 15/15] PCI/TSM: Add relative MMIO offset support? Dan Williams
2026-07-08  2:25   ` Alexey Kardashevskiy
2026-07-08 18:05     ` Dan Williams (nvidia)
2026-07-06 12:51 ` [PATCH 00/15] Device Evidence and Trust for PCI Security Protocol (TDISP) Jason Gunthorpe
2026-07-06 20:55   ` Dan Williams (nvidia)
2026-07-07 12:43     ` Jason Gunthorpe
2026-07-08  0:12       ` Dan Williams (nvidia)
2026-07-08 14:31         ` Jason Gunthorpe
2026-07-09  2:45           ` Dan Williams (nvidia)
2026-07-09 13:36             ` Jason Gunthorpe

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=39809986-74dd-476f-ba61-a0a9187862d5@amd.com \
    --to=aik@amd.com \
    --cc=ankita@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=dakr@kernel.org \
    --cc=decui@microsoft.com \
    --cc=djbw@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@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