From: Alexey Kardashevskiy <aik@amd.com>
To: Dan Williams <dan.j.williams@intel.com>,
linux-coco@lists.linux.dev, linux-pci@vger.kernel.org
Cc: gregkh@linuxfoundation.org, bhelgaas@google.com,
yilun.xu@linux.intel.com, aneesh.kumar@kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 4/7] x86/ioremap, resource: Introduce IORES_DESC_ENCRYPTED for encrypted PCI MMIO
Date: Wed, 8 Oct 2025 08:31:44 +1100 [thread overview]
Message-ID: <b3be3792-6dbc-4ec7-af34-f80ecb516de7@amd.com> (raw)
In-Reply-To: <f6d07595-0009-447f-b694-605625c04b8f@amd.com>
On 7/10/25 19:23, Alexey Kardashevskiy wrote:
>
>
> On 27/8/25 13:52, Dan Williams wrote:
>> PCIe Trusted Execution Environment Device Interface Security Protocol
>> (TDISP) arranges for a PCI device to support encrypted MMIO. In support of
>> that capability, ioremap() needs a mechanism to detect when a PCI device
>> has been dynamically transitioned into this secure state and enforce
>> encrypted MMIO mappings.
>>
>> Teach ioremap() about a new IORES_DESC_ENCRYPTED type that supplements the
>> existing PCI Memory Space (MMIO) BAR resources. The proposal is that a
>> resource, "PCI MMIO Encrypted", with this description type is injected by
>> the PCI/TSM core for each PCI device BAR that is to be protected.
>>
>> Unlike the existing encryption determination which is "implied with a silent
>> fallback to an unencrypted mapping", this indication is "explicit with an
>> expectation that the request fails instead of fallback". IORES_MUST_ENCRYPT
>> is added to manage this expectation.
>>
>> Given that "PCI MMIO Encrypted" is an additional resource in the tree, the
>> IORESOURCE_BUSY flag will only be set on a descendant/child of that
>> resource. Adjust the resource tree walk to use walk_iomem_res_desc() and
>> check all intersecting resources for the IORES_MUST_ENCRYPT determination.
>
> How is this expected to work exactly?
>
> samples/devsec/tsm.c calls pci_tsm_alloc_encrypted_resources() which essentially does:
>
> *__res[i] = DEFINE_RES_NAMED_DESC(pci_resource_start(pdev, i),
> len, "PCI MMIO Encrypted",
> flags, IORES_DESC_ENCRYPTED);
> if (insert_resource(&iomem_resource, __res[i]) != 0) {
> ...
>
> By later on pci_iomap(pdev, N, PAGE_SIZE) on that BAR maps as unencrypted. The resource makes it to (hacked) iomem:
>
> c000000000-c7ffffffff : PCI Bus 0000:00 fl=200201 desc=0
> c000000000-c01fffffff : PCI Bus 0000:01 fl=102201 desc=0
> c000000000-c003ffffff : 0000:01:00.0 fl=14220c desc=0
> c000000000-c003ffffff : mydrv fl=80000200 desc=0
> c004000000-c004000fff : PCI MMIO Encrypted fl=14220c desc=a
> c004000000-c004000fff : 0000:01:00.0 fl=14220c desc=0
> c004001000-c004001fff : 0000:01:00.0 fl=14220c desc=0
>
>
> and btw does not pci_resource_n(pdev, i) make more sense as a parent in insert_resource().
>
>
>>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: x86@kernel.org
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>> arch/x86/mm/ioremap.c | 32 +++++++++++++++++++++-----------
>> include/linux/ioport.h | 2 ++
>> 2 files changed, 23 insertions(+), 11 deletions(-)
>>
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index 12c8180ca1ba..78b677dadfdc 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -93,18 +93,24 @@ static unsigned int __ioremap_check_ram(struct resource *res)
>> */
>> static unsigned int __ioremap_check_encrypted(struct resource *res)
>> {
>> + u32 flags = 0;
>> +
>> + if (res->desc == IORES_DESC_ENCRYPTED)
>> + flags |= IORES_MUST_ENCRYPT;
>> +
>> if (!cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
>> - return 0;
>> + return flags;
>> switch (res->desc) {
>> case IORES_DESC_NONE:
>> case IORES_DESC_RESERVED:
>> break;
>> + case IORES_DESC_ENCRYPTED:
>> default:
>> - return IORES_MAP_ENCRYPTED;
>> + flags |= IORES_MAP_ENCRYPTED;
>> }
>> - return 0;
>> + return flags;
>> }
>> /*
>> @@ -134,14 +140,10 @@ static int __ioremap_collect_map_flags(struct resource *res, void *arg)
>> {
>> struct ioremap_desc *desc = arg;
>> - if (!(desc->flags & IORES_MAP_SYSTEM_RAM))
>> - desc->flags |= __ioremap_check_ram(res);
>> -
>> - if (!(desc->flags & IORES_MAP_ENCRYPTED))
>> - desc->flags |= __ioremap_check_encrypted(res);
>> + desc->flags |= __ioremap_check_ram(res);
>> + desc->flags |= __ioremap_check_encrypted(res);
>
>
> Here the found "res" is actually "c000000000-c7ffffffff : PCI Bus 0000:00", not c004000000 (from the above example)...
>
>> - return ((desc->flags & (IORES_MAP_SYSTEM_RAM | IORES_MAP_ENCRYPTED)) ==
>> - (IORES_MAP_SYSTEM_RAM | IORES_MAP_ENCRYPTED));
>> + return 0;
>> }
>> /*
>> @@ -161,7 +163,8 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size,
>> end = start + size - 1;
>> memset(desc, 0, sizeof(struct ioremap_desc));
Adding this here:
+ walk_iomem_res_desc(IORES_DESC_ENCRYPTED, IORESOURCE_MEM, start, end, desc,
+ __ioremap_collect_map_flags);
fixed the problem and the encryption bit is set. Thanks,
>> - walk_mem_res(start, end, desc, __ioremap_collect_map_flags);
>> + walk_iomem_res_desc(IORES_DESC_NONE, IORESOURCE_MEM, start, end, desc,
>> + __ioremap_collect_map_flags);
>
>
> ... which seems to be the result of passing IORES_DESC_NONE. What do I miss? Thanks,
>
>
>> __ioremap_check_other(addr, desc);
>> }
>> @@ -209,6 +212,13 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
>> __ioremap_check_mem(phys_addr, size, &io_desc);
>> + if ((io_desc.flags & IORES_MUST_ENCRYPT) &&
>> + !(io_desc.flags & IORES_MAP_ENCRYPTED)) {
>> + pr_err("ioremap: encrypted mapping unavailable for %pa - %pa\n",
>> + &phys_addr, &last_addr);
>> + return NULL;
>> + }
>> +
>> /*
>> * Don't allow anybody to remap normal RAM that we're using..
>> */
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index e8b2d6aa4013..b46e42bcafe3 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -143,6 +143,7 @@ enum {
>> IORES_DESC_RESERVED = 7,
>> IORES_DESC_SOFT_RESERVED = 8,
>> IORES_DESC_CXL = 9,
>> + IORES_DESC_ENCRYPTED = 10,
>> };
>> /*
>> @@ -151,6 +152,7 @@ enum {
>> enum {
>> IORES_MAP_SYSTEM_RAM = BIT(0),
>> IORES_MAP_ENCRYPTED = BIT(1),
>> + IORES_MUST_ENCRYPT = BIT(2), /* disable transparent fallback */
>> };
>> /* helpers to define resources */
>
--
Alexey
next prev parent reply other threads:[~2025-10-07 21:32 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 3:52 [PATCH 0/7] PCI/TSM: TEE I/O infrastructure Dan Williams
2025-08-27 3:52 ` [PATCH 1/7] PCI/TSM: Add pci_tsm_{bind,unbind}() methods for instantiating TDIs Dan Williams
2025-09-02 0:12 ` Alexey Kardashevskiy
2025-09-02 15:04 ` Aneesh Kumar K.V
2025-09-10 4:47 ` dan.j.williams
2025-09-10 4:46 ` dan.j.williams
2025-09-02 15:05 ` Aneesh Kumar K.V
2025-09-10 4:50 ` dan.j.williams
2025-09-03 15:17 ` Aneesh Kumar K.V
2025-09-04 10:38 ` Alexey Kardashevskiy
2025-09-04 12:56 ` Aneesh Kumar K.V
2025-09-05 2:32 ` Alexey Kardashevskiy
2025-09-10 5:09 ` dan.j.williams
2025-08-27 3:52 ` [PATCH 2/7] PCI/TSM: Add pci_tsm_guest_req() for managing TDIs Dan Williams
2025-08-28 9:53 ` Alexey Kardashevskiy
2025-08-28 22:07 ` dan.j.williams
2025-08-29 2:21 ` Alexey Kardashevskiy
2025-08-30 2:37 ` dan.j.williams
2025-09-01 23:49 ` Alexey Kardashevskiy
2025-09-08 11:09 ` Alexey Kardashevskiy
2025-09-10 5:35 ` dan.j.williams
2025-10-10 4:48 ` Xu Yilun
2025-08-28 13:02 ` Aneesh Kumar K.V
2025-08-28 22:14 ` dan.j.williams
2025-08-27 3:52 ` [PATCH 3/7] device core: Introduce confidential device acceptance Dan Williams
2025-08-27 6:14 ` Greg KH
2025-08-28 20:07 ` dan.j.williams
2025-09-16 16:58 ` Jonathan Cameron
2025-08-27 3:52 ` [PATCH 4/7] x86/ioremap, resource: Introduce IORES_DESC_ENCRYPTED for encrypted PCI MMIO Dan Williams
2025-09-17 21:30 ` Jason Gunthorpe
2025-10-07 8:23 ` Alexey Kardashevskiy
2025-10-07 21:31 ` Alexey Kardashevskiy [this message]
2025-08-27 3:52 ` [PATCH 5/7] PCI/TSM: Add Device Security (TVM Guest) operations support Dan Williams
2025-09-03 15:22 ` Aneesh Kumar K.V
2025-09-10 5:15 ` dan.j.williams
2025-09-11 8:31 ` Aneesh Kumar K.V
2025-09-04 15:02 ` Aneesh Kumar K.V
2025-09-10 5:31 ` dan.j.williams
2025-09-16 17:10 ` Jonathan Cameron
2025-08-27 3:52 ` [PATCH 6/7] samples/devsec: Introduce a "Device Security TSM" sample driver Dan Williams
2025-08-27 12:39 ` Jason Gunthorpe
2025-08-27 23:47 ` Alexey Kardashevskiy
2025-08-28 21:38 ` dan.j.williams
2025-08-29 16:02 ` Jason Gunthorpe
2025-08-29 20:00 ` dan.j.williams
2025-08-29 23:34 ` Jason Gunthorpe
2025-08-27 3:52 ` [PATCH 7/7] tools/testing/devsec: Add a script to exercise samples/devsec/ Dan Williams
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=b3be3792-6dbc-4ec7-af34-f80ecb516de7@amd.com \
--to=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yilun.xu@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).