[PATCH 0/3] arm64: realm: Add support for encrypted data from firmware

[PATCH 0/3] arm64: realm: Add support for encrypted data from firmware

[Suzuki K Poulose]

Confidential compute firmware may provide secret data via reserved memory regions
(e.g., ACPI CCEL, EFI Coco secret area). These must be ioremap'ed() as encrypted.
As of now, realm only maps "trusted devices" (RIPAS = RSI_RIPAS_DEV) as encrypted.
This series adds support for mapping areas that are protected
(i.e., RIPAS = RSI_RIPAS_RAM) as encrypted. Also, extrapolating that, we can map
anything that is not RIPAS_EMPTY as protected, as it is guaranteed to be "protected".

With this in place, we can naturally map any firmware provided area based on the
RIPAS value. If the firmware provides a shared region (not trusted), it must have
set the RIPAS accordingly, before placing the data, as the transition is always
destructive.

Also enables the EFI Coco secret area support and Confidential Compute Event
Log (CCEL) for arm64.


Suzuki K Poulose (3):
  arm64: realm: ioremap: Allow mapping memory as encrypted
  arm64: Enable EFI secret area Securityfs support
  arm64: acpi: Enable ACPI CCEL support

 arch/arm64/include/asm/io.h          |  6 +++++-
 arch/arm64/include/asm/rsi.h         |  2 +-
 arch/arm64/kernel/acpi.c             |  5 +++++
 arch/arm64/kernel/rsi.c              | 26 ++++++++++++++++++++++----
 drivers/virt/coco/efi_secret/Kconfig |  2 +-
 5 files changed, 34 insertions(+), 7 deletions(-)

-- 
2.43.0

[PATCH 1/3] arm64: realm: ioremap: Allow mapping memory as encrypted

[Suzuki K Poulose]

For ioremap(), so far we only checked if it was a device (RIPAS_DEV) to choose
an encrypted vs decrypted mapping. However, we may have firmware reserved memory
regions exposed to the OS (e.g., EFI Coco Secret Securityfs, ACPI CCEL).
We need to make sure that anything that is RIPAS_RAM (i.e., Guest
protected memory with RMM guarantees) are also mapped as encrypted.

Rephrasing the above, anything that is not RIPAS_EMPTY is guaranteed to be
protected by the RMM. Thus we choose encrypted mapping for anything that is not
RIPAS_EMPTY. While at it, rename the helper function

  __arm64_is_protected_mmio => arm64_rsi_is_protected

to clearly indicate that this not an arm64 generic helper, but something to do
with Realms.

Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/include/asm/io.h  |  2 +-
 arch/arm64/include/asm/rsi.h |  2 +-
 arch/arm64/kernel/rsi.c      | 26 ++++++++++++++++++++++----
 3 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 9b96840fb979..82276282a3c7 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -311,7 +311,7 @@ extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
 static inline bool arm64_is_protected_mmio(phys_addr_t phys_addr, size_t size)
 {
 	if (unlikely(is_realm_world()))
-		return __arm64_is_protected_mmio(phys_addr, size);
+		return arm64_rsi_is_protected(phys_addr, size);
 	return false;
 }
 
diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
index b42aeac05340..88b50d660e85 100644
--- a/arch/arm64/include/asm/rsi.h
+++ b/arch/arm64/include/asm/rsi.h
@@ -16,7 +16,7 @@ DECLARE_STATIC_KEY_FALSE(rsi_present);
 
 void __init arm64_rsi_init(void);
 
-bool __arm64_is_protected_mmio(phys_addr_t base, size_t size);
+bool arm64_rsi_is_protected(phys_addr_t base, size_t size);
 
 static inline bool is_realm_world(void)
 {
diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
index ce4778141ec7..c64a06f58c0b 100644
--- a/arch/arm64/kernel/rsi.c
+++ b/arch/arm64/kernel/rsi.c
@@ -84,7 +84,25 @@ static void __init arm64_rsi_setup_memory(void)
 	}
 }
 
-bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
+/*
+ * Check if a given PA range is Trusted (e.g., Protected memory, a Trusted Device
+ * mapping, or an MMIO emulated in the Realm world).
+ *
+ * We can rely on the RIPAS value of the region to detect if a given region is
+ * protected.
+ *
+ *  RIPAS_DEV - A trusted device memory or a trusted emulated MMIO (in the Realm
+ *		world
+ *  RIPAS_RAM - Memory (RAM), protected by the RMM guarantees. (e.g., Firmware
+ *		reserved regions for data sharing).
+ *
+ *  RIPAS_DESTROYED is a special case of one of the above, where the host did
+ *  something without our permission and as such we can't do anything about it.
+ *
+ * The only case where something is emulated by the untrusted hypervisor or is
+ * backed by shared memory is indicated by RSI_RIPAS_EMPTY.
+ */
+bool arm64_rsi_is_protected(phys_addr_t base, size_t size)
 {
 	enum ripas ripas;
 	phys_addr_t end, top;
@@ -101,18 +119,18 @@ bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
 			break;
 		if (WARN_ON(top <= base))
 			break;
-		if (ripas != RSI_RIPAS_DEV)
+		if (ripas == RSI_RIPAS_EMPTY)
 			break;
 		base = top;
 	}
 
 	return base >= end;
 }
-EXPORT_SYMBOL(__arm64_is_protected_mmio);
+EXPORT_SYMBOL(arm64_rsi_is_protected);
 
 static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
 {
-	if (__arm64_is_protected_mmio(phys, size))
+	if (arm64_rsi_is_protected(phys, size))
 		*prot = pgprot_encrypted(*prot);
 	else
 		*prot = pgprot_decrypted(*prot);
-- 
2.43.0

Re: [PATCH 1/3] arm64: realm: ioremap: Allow mapping memory as encrypted

[Steven Price]

On 13/06/2025 12:11, Suzuki K Poulose wrote:
> For ioremap(), so far we only checked if it was a device (RIPAS_DEV) to choose
> an encrypted vs decrypted mapping. However, we may have firmware reserved memory
> regions exposed to the OS (e.g., EFI Coco Secret Securityfs, ACPI CCEL).
> We need to make sure that anything that is RIPAS_RAM (i.e., Guest
> protected memory with RMM guarantees) are also mapped as encrypted.
> 
> Rephrasing the above, anything that is not RIPAS_EMPTY is guaranteed to be
> protected by the RMM. Thus we choose encrypted mapping for anything that is not
> RIPAS_EMPTY. While at it, rename the helper function
> 
>   __arm64_is_protected_mmio => arm64_rsi_is_protected
> 
> to clearly indicate that this not an arm64 generic helper, but something to do
> with Realms.
> 
> Cc: Sami Mujawar <sami.mujawar@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>

Reviewed-by: Steven Price <steven.price@arm.com>

> ---
>  arch/arm64/include/asm/io.h  |  2 +-
>  arch/arm64/include/asm/rsi.h |  2 +-
>  arch/arm64/kernel/rsi.c      | 26 ++++++++++++++++++++++----
>  3 files changed, 24 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 9b96840fb979..82276282a3c7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -311,7 +311,7 @@ extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
>  static inline bool arm64_is_protected_mmio(phys_addr_t phys_addr, size_t size)
>  {
>  	if (unlikely(is_realm_world()))
> -		return __arm64_is_protected_mmio(phys_addr, size);
> +		return arm64_rsi_is_protected(phys_addr, size);
>  	return false;
>  }
>  
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index b42aeac05340..88b50d660e85 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -16,7 +16,7 @@ DECLARE_STATIC_KEY_FALSE(rsi_present);
>  
>  void __init arm64_rsi_init(void);
>  
> -bool __arm64_is_protected_mmio(phys_addr_t base, size_t size);
> +bool arm64_rsi_is_protected(phys_addr_t base, size_t size);
>  
>  static inline bool is_realm_world(void)
>  {
> diff --git a/arch/arm64/kernel/rsi.c b/arch/arm64/kernel/rsi.c
> index ce4778141ec7..c64a06f58c0b 100644
> --- a/arch/arm64/kernel/rsi.c
> +++ b/arch/arm64/kernel/rsi.c
> @@ -84,7 +84,25 @@ static void __init arm64_rsi_setup_memory(void)
>  	}
>  }
>  
> -bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
> +/*
> + * Check if a given PA range is Trusted (e.g., Protected memory, a Trusted Device
> + * mapping, or an MMIO emulated in the Realm world).
> + *
> + * We can rely on the RIPAS value of the region to detect if a given region is
> + * protected.
> + *
> + *  RIPAS_DEV - A trusted device memory or a trusted emulated MMIO (in the Realm
> + *		world
> + *  RIPAS_RAM - Memory (RAM), protected by the RMM guarantees. (e.g., Firmware
> + *		reserved regions for data sharing).
> + *
> + *  RIPAS_DESTROYED is a special case of one of the above, where the host did
> + *  something without our permission and as such we can't do anything about it.
> + *
> + * The only case where something is emulated by the untrusted hypervisor or is
> + * backed by shared memory is indicated by RSI_RIPAS_EMPTY.
> + */
> +bool arm64_rsi_is_protected(phys_addr_t base, size_t size)
>  {
>  	enum ripas ripas;
>  	phys_addr_t end, top;
> @@ -101,18 +119,18 @@ bool __arm64_is_protected_mmio(phys_addr_t base, size_t size)
>  			break;
>  		if (WARN_ON(top <= base))
>  			break;
> -		if (ripas != RSI_RIPAS_DEV)
> +		if (ripas == RSI_RIPAS_EMPTY)
>  			break;
>  		base = top;
>  	}
>  
>  	return base >= end;
>  }
> -EXPORT_SYMBOL(__arm64_is_protected_mmio);
> +EXPORT_SYMBOL(arm64_rsi_is_protected);
>  
>  static int realm_ioremap_hook(phys_addr_t phys, size_t size, pgprot_t *prot)
>  {
> -	if (__arm64_is_protected_mmio(phys, size))
> +	if (arm64_rsi_is_protected(phys, size))
>  		*prot = pgprot_encrypted(*prot);
>  	else
>  		*prot = pgprot_decrypted(*prot);

Re: [PATCH 1/3] arm64: realm: ioremap: Allow mapping memory as encrypted

[Gavin Shan]

On 6/13/25 9:11 PM, Suzuki K Poulose wrote:
> For ioremap(), so far we only checked if it was a device (RIPAS_DEV) to choose
> an encrypted vs decrypted mapping. However, we may have firmware reserved memory
> regions exposed to the OS (e.g., EFI Coco Secret Securityfs, ACPI CCEL).
> We need to make sure that anything that is RIPAS_RAM (i.e., Guest
> protected memory with RMM guarantees) are also mapped as encrypted.
> 
> Rephrasing the above, anything that is not RIPAS_EMPTY is guaranteed to be
> protected by the RMM. Thus we choose encrypted mapping for anything that is not
> RIPAS_EMPTY. While at it, rename the helper function
> 
>    __arm64_is_protected_mmio => arm64_rsi_is_protected
> 
> to clearly indicate that this not an arm64 generic helper, but something to do
> with Realms.
> 
> Cc: Sami Mujawar <sami.mujawar@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>   arch/arm64/include/asm/io.h  |  2 +-
>   arch/arm64/include/asm/rsi.h |  2 +-
>   arch/arm64/kernel/rsi.c      | 26 ++++++++++++++++++++++----
>   3 files changed, 24 insertions(+), 6 deletions(-)
> 

Reviewed-by: Gavin Shan <gshan@redhat.com>

[PATCH 2/3] arm64: Enable EFI secret area Securityfs support

[Suzuki K Poulose]

Enable EFI COCO secrets support. Provide the ioremap_encrypted() support required
by the driver.

Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/include/asm/io.h          | 4 ++++
 drivers/virt/coco/efi_secret/Kconfig | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 82276282a3c7..83e03abbb2ca 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -274,6 +274,10 @@ int arm64_ioremap_prot_hook_register(const ioremap_prot_hook_t hook);
 #define ioremap_np(addr, size)	\
 	ioremap_prot((addr), (size), __pgprot(PROT_DEVICE_nGnRnE))
 
+
+#define ioremap_encrypted(addr, size)	\
+	ioremap_prot((addr), (size), PAGE_KERNEL)
+
 /*
  * io{read,write}{16,32,64}be() macros
  */
diff --git a/drivers/virt/coco/efi_secret/Kconfig b/drivers/virt/coco/efi_secret/Kconfig
index 4404d198f3b2..94d88e5da707 100644
--- a/drivers/virt/coco/efi_secret/Kconfig
+++ b/drivers/virt/coco/efi_secret/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config EFI_SECRET
 	tristate "EFI secret area securityfs support"
-	depends on EFI && X86_64
+	depends on EFI && (X86_64 || ARM64)
 	select EFI_COCO_SECRET
 	select SECURITYFS
 	help
-- 
2.43.0

Re: [PATCH 2/3] arm64: Enable EFI secret area Securityfs support

[Gavin Shan]

On 6/13/25 9:11 PM, Suzuki K Poulose wrote:
> Enable EFI COCO secrets support. Provide the ioremap_encrypted() support required
> by the driver.
> 
> Cc: Sami Mujawar <sami.mujawar@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>   arch/arm64/include/asm/io.h          | 4 ++++
>   drivers/virt/coco/efi_secret/Kconfig | 2 +-
>   2 files changed, 5 insertions(+), 1 deletion(-)
> 

Reviewed-by: Gavin Shan <gshan@redhat.com>

[PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Suzuki K Poulose]

ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
PAGE_KERNEL.

Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
 arch/arm64/kernel/acpi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b9a66fc146c9..f52439d411a0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
 			prot = PAGE_KERNEL_RO;
 			break;
 
+		case EFI_ACPI_MEMORY_NVS:
+			/* Non-volatile storage, required for CCEL */
+			prot = PAGE_KERNEL;
+			break;
+
 		case EFI_ACPI_RECLAIM_MEMORY:
 			/*
 			 * ACPI reclaim memory is used to pass firmware tables
-- 
2.43.0

Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Gavin Shan]

On 6/13/25 9:11 PM, Suzuki K Poulose wrote:
> ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
> PAGE_KERNEL.
> 
> Cc: Sami Mujawar <sami.mujawar@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>   arch/arm64/kernel/acpi.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
Reviewed-by: Gavin Shan <gshan@redhat.com>

Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Will Deacon]

On Fri, Jun 13, 2025 at 12:11:53PM +0100, Suzuki K Poulose wrote:
> ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
> PAGE_KERNEL.

It would be helpful to have a citation for that. I've tried digging it
out of the ACPI spec, but that pointed me to the Intel TDX site and I
got lost in whitepapers :/

> Cc: Sami Mujawar <sami.mujawar@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  arch/arm64/kernel/acpi.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b9a66fc146c9..f52439d411a0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>  			prot = PAGE_KERNEL_RO;
>  			break;
>  
> +		case EFI_ACPI_MEMORY_NVS:
> +			/* Non-volatile storage, required for CCEL */
> +			prot = PAGE_KERNEL;

By "storage" you just mean memory, right?

Will

Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Suzuki K Poulose]

On 15/07/2025 14:56, Will Deacon wrote:
> On Fri, Jun 13, 2025 at 12:11:53PM +0100, Suzuki K Poulose wrote:
>> ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
>> PAGE_KERNEL.
> 
> It would be helpful to have a citation for that. I've tried digging it
> out of the ACPI spec, but that pointed me to the Intel TDX site and I
> got lost in whitepapers :/
> 

https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#cc-event-log-acpi-table

>> Cc: Sami Mujawar <sami.mujawar@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
>> Cc: Steven Price <steven.price@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>   arch/arm64/kernel/acpi.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index b9a66fc146c9..f52439d411a0 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>>   			prot = PAGE_KERNEL_RO;
>>   			break;
>>   
>> +		case EFI_ACPI_MEMORY_NVS:
>> +			/* Non-volatile storage, required for CCEL */
>> +			prot = PAGE_KERNEL;
> 
> By "storage" you just mean memory, right?

Yep, it is just memory. I will drop the "NV storage" and simply mention, 
CCEL.

Thanks!

Suzuki


> 
> Will

Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Will Deacon]

On Tue, Jul 15, 2025 at 03:38:41PM +0100, Suzuki K Poulose wrote:
> On 15/07/2025 14:56, Will Deacon wrote:
> > On Fri, Jun 13, 2025 at 12:11:53PM +0100, Suzuki K Poulose wrote:
> > > ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
> > > PAGE_KERNEL.
> > 
> > It would be helpful to have a citation for that. I've tried digging it
> > out of the ACPI spec, but that pointed me to the Intel TDX site and I
> > got lost in whitepapers :/
> > 
> 
> https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#cc-event-log-acpi-table

Thanks, but I still can't spot where it specifies the memory attributes.
I think we should be able to refer to that as justification for ignoring
the attributes specified by EFI.

> > > Cc: Sami Mujawar <sami.mujawar@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
> > > Cc: Steven Price <steven.price@arm.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > >   arch/arm64/kernel/acpi.c | 5 +++++
> > >   1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > index b9a66fc146c9..f52439d411a0 100644
> > > --- a/arch/arm64/kernel/acpi.c
> > > +++ b/arch/arm64/kernel/acpi.c
> > > @@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
> > >   			prot = PAGE_KERNEL_RO;
> > >   			break;
> > > +		case EFI_ACPI_MEMORY_NVS:
> > > +			/* Non-volatile storage, required for CCEL */
> > > +			prot = PAGE_KERNEL;
> > 
> > By "storage" you just mean memory, right?
> 
> Yep, it is just memory. I will drop the "NV storage" and simply mention,
> CCEL.

Thanks. Also, why don't we check against memblock_is_map_memory() for
this, like we do for all the other types apart from
EFI_RUNTIME_SERVICES_CODE?

Will

Re: [PATCH 3/3] arm64: acpi: Enable ACPI CCEL support

[Suzuki K Poulose]

Hi Will

On 15/07/2025 15:58, Will Deacon wrote:
> On Tue, Jul 15, 2025 at 03:38:41PM +0100, Suzuki K Poulose wrote:
>> On 15/07/2025 14:56, Will Deacon wrote:
>>> On Fri, Jun 13, 2025 at 12:11:53PM +0100, Suzuki K Poulose wrote:
>>>> ACPI CCEL memory area is reported as Non-Volatile storage area. Map it as
>>>> PAGE_KERNEL.
>>>
>>> It would be helpful to have a citation for that. I've tried digging it
>>> out of the ACPI spec, but that pointed me to the Intel TDX site and I
>>> got lost in whitepapers :/
>>>
>>
>> https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#cc-event-log-acpi-table
> 
> Thanks, but I still can't spot where it specifies the memory attributes.
> I think we should be able to refer to that as justification for ignoring
> the attributes specified by EFI.

Here is the description for the Efi memory types.

https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#memory-type-usage-before-exitbootservices

 From that I gather that OS must map the area as read only.

> 
>>>> Cc: Sami Mujawar <sami.mujawar@arm.com>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
>>>> Cc: Steven Price <steven.price@arm.com>
>>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>>    arch/arm64/kernel/acpi.c | 5 +++++
>>>>    1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>>> index b9a66fc146c9..f52439d411a0 100644
>>>> --- a/arch/arm64/kernel/acpi.c
>>>> +++ b/arch/arm64/kernel/acpi.c
>>>> @@ -356,6 +356,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
>>>>    			prot = PAGE_KERNEL_RO;
>>>>    			break;
>>>> +		case EFI_ACPI_MEMORY_NVS:
>>>> +			/* Non-volatile storage, required for CCEL */
>>>> +			prot = PAGE_KERNEL;
>>>
>>> By "storage" you just mean memory, right?
>>
>> Yep, it is just memory. I will drop the "NV storage" and simply mention,
>> CCEL.
> 
> Thanks. Also, why don't we check against memblock_is_map_memory() for
> this, like we do for all the other types apart from
> EFI_RUNTIME_SERVICES_CODE?

As per the spec, the NVS type must be reserved and we do that in the
kernel. For the other types, you mentioned, they are usable by
general OS and in Linux we only reserve them, if they are have
WB attribute (See is_usable_memory()). Thus we do extra checks to
make sure, if it is in use and mark them as RO.

So, NVS is by default reserved and doesn't have to do extra checks.

That said, I will fix the prot to PAGE_KERNEL_RO to make sure
the OS doesn't write to it.

Thanks
Suzuki

> 
> Will

Re: [PATCH 0/3] arm64: realm: Add support for encrypted data from firmware

[Suzuki K Poulose]

On 13/06/2025 12:11, Suzuki K Poulose wrote:
> Confidential compute firmware may provide secret data via reserved memory regions
> (e.g., ACPI CCEL, EFI Coco secret area). These must be ioremap'ed() as encrypted.
> As of now, realm only maps "trusted devices" (RIPAS = RSI_RIPAS_DEV) as encrypted.
> This series adds support for mapping areas that are protected
> (i.e., RIPAS = RSI_RIPAS_RAM) as encrypted. Also, extrapolating that, we can map
> anything that is not RIPAS_EMPTY as protected, as it is guaranteed to be "protected".
> 
> With this in place, we can naturally map any firmware provided area based on the
> RIPAS value. If the firmware provides a shared region (not trusted), it must have
> set the RIPAS accordingly, before placing the data, as the transition is always
> destructive.
> 
> Also enables the EFI Coco secret area support and Confidential Compute Event
> Log (CCEL) for arm64.
> 

A branch with the patches is also available here:

git@git.gitlab.arm.com:linux-arm/linux-cca.git  cca-guest/coco-secret/v1


Suzuki


> 
> Suzuki K Poulose (3):
>    arm64: realm: ioremap: Allow mapping memory as encrypted
>    arm64: Enable EFI secret area Securityfs support
>    arm64: acpi: Enable ACPI CCEL support
> 
>   arch/arm64/include/asm/io.h          |  6 +++++-
>   arch/arm64/include/asm/rsi.h         |  2 +-
>   arch/arm64/kernel/acpi.c             |  5 +++++
>   arch/arm64/kernel/rsi.c              | 26 ++++++++++++++++++++++----
>   drivers/virt/coco/efi_secret/Kconfig |  2 +-
>   5 files changed, 34 insertions(+), 7 deletions(-)
> 

Re: [PATCH 0/3] arm64: realm: Add support for encrypted data from firmware

[Sami Mujawar]

For this series.

Tested-by: Sami Mujawar <sami.mujawar@arm.com>

Thanks.

Regards,

Sami Mujawar


On 16/06/2025, 12:15, "Suzuki K Poulose" <suzuki.poulose@arm.com <mailto:suzuki.poulose@arm.com>> wrote:


On 13/06/2025 12:11, Suzuki K Poulose wrote:
> Confidential compute firmware may provide secret data via reserved memory regions
> (e.g., ACPI CCEL, EFI Coco secret area). These must be ioremap'ed() as encrypted.
> As of now, realm only maps "trusted devices" (RIPAS = RSI_RIPAS_DEV) as encrypted.
> This series adds support for mapping areas that are protected
> (i.e., RIPAS = RSI_RIPAS_RAM) as encrypted. Also, extrapolating that, we can map
> anything that is not RIPAS_EMPTY as protected, as it is guaranteed to be "protected".
> 
> With this in place, we can naturally map any firmware provided area based on the
> RIPAS value. If the firmware provides a shared region (not trusted), it must have
> set the RIPAS accordingly, before placing the data, as the transition is always
> destructive.
> 
> Also enables the EFI Coco secret area support and Confidential Compute Event
> Log (CCEL) for arm64.
> 


A branch with the patches is also available here:


git@git.gitlab.arm.com <mailto:git@git.gitlab.arm.com>:linux-arm/linux-cca.git cca-guest/coco-secret/v1




Suzuki




> 
> Suzuki K Poulose (3):
> arm64: realm: ioremap: Allow mapping memory as encrypted
> arm64: Enable EFI secret area Securityfs support
> arm64: acpi: Enable ACPI CCEL support
> 
> arch/arm64/include/asm/io.h | 6 +++++-
> arch/arm64/include/asm/rsi.h | 2 +-
> arch/arm64/kernel/acpi.c | 5 +++++
> arch/arm64/kernel/rsi.c | 26 ++++++++++++++++++++++----
> drivers/virt/coco/efi_secret/Kconfig | 2 +-
> 5 files changed, 34 insertions(+), 7 deletions(-)
> 

Re: [PATCH 0/3] arm64: realm: Add support for encrypted data from firmware

[Suzuki K Poulose]

On 13/06/2025 12:11, Suzuki K Poulose wrote:
> Confidential compute firmware may provide secret data via reserved memory regions
> (e.g., ACPI CCEL, EFI Coco secret area). These must be ioremap'ed() as encrypted.
> As of now, realm only maps "trusted devices" (RIPAS = RSI_RIPAS_DEV) as encrypted.
> This series adds support for mapping areas that are protected
> (i.e., RIPAS = RSI_RIPAS_RAM) as encrypted. Also, extrapolating that, we can map
> anything that is not RIPAS_EMPTY as protected, as it is guaranteed to be "protected".
> 
> With this in place, we can naturally map any firmware provided area based on the
> RIPAS value. If the firmware provides a shared region (not trusted), it must have
> set the RIPAS accordingly, before placing the data, as the transition is always
> destructive.
> 
> Also enables the EFI Coco secret area support and Confidential Compute Event
> Log (CCEL) for arm64.
> 
> 
> Suzuki K Poulose (3):
>    arm64: realm: ioremap: Allow mapping memory as encrypted
>    arm64: Enable EFI secret area Securityfs support
>    arm64: acpi: Enable ACPI CCEL support
> 
>   arch/arm64/include/asm/io.h          |  6 +++++-
>   arch/arm64/include/asm/rsi.h         |  2 +-
>   arch/arm64/kernel/acpi.c             |  5 +++++
>   arch/arm64/kernel/rsi.c              | 26 ++++++++++++++++++++++----
>   drivers/virt/coco/efi_secret/Kconfig |  2 +-
>   5 files changed, 34 insertions(+), 7 deletions(-)
> 

Gentle ping

Kind regards
Suzuki