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(-)
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
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
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(-) >
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(-) >
© 2016 - 2025 Red Hat, Inc.