From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Kohei Enju <enju.kohei@fujitsu.com>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Sami Mujawar <sami.mujawar@arm.com>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Jiri Pirko <jiri@resnulli.us>, GONG Ruiqi <gongruiqi1@huawei.com>,
Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH RFC 1/3] firmware: arm_firme: introduce arm_firme driver
Date: Thu, 22 Oct 2026 14:17:23 +0100 [thread overview]
Message-ID: <atoM447tWm2EsoSP@e129823.arm.com> (raw)
In-Reply-To: <atnVCFWZLKR8GthP@FCCLS0092175.localdomain>
On Thu, Oct 22, 2026 at 06:48:49PM +0900, Kohei Enju wrote:
> On 10/19 15:14, Yeoreum Yun wrote:
> > The Realm Management Extension (FEAT_RME) is part of Arm Confidential
> > Compute Architecture (CCA) and enables support for dynamic, attestable
> > trusted execution environments ("Realms") on Arm systems.
> >
> > Realm management flows depend on EL3 firmware for operations such as
> > Realm construction, resource allocation and isolation, and attestation
> > of initial Realm state.
> >
> > The FIRME defines standard interfaces provided by EL3 firmware to
> > satisfy these dependencies. These interfaces include:
> >
> > - Granule Protection Table management
> > - IDE key management for PCIe and CXL Root Ports
> > - Memory Encryption Context management
> > - Attestation token management
> > - Integrated device management
> >
> > Each group of interfaces forms a FIRME service. A base FIRME service
> > is also defined to provide common concepts, service discovery, and
> > feature discovery across services.
> >
> > FIRME interfaces are implemented at the EL3 boundary between the
> > Non-secure, Realm, and Secure states. They may also be used on systems
> > without FEAT_RME, for example to provide firmware-based attestation or
> > security services.
> >
> > arm_firme driver provides the common FIRME framework and service discovery
> > support for client drivers using below FIRME services:
> >
> > - Base service.
> > - Attestation token management.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>
> Does this series assume that the kernel is running in EL2 implicitly?
>
> The FIRME spec says:
> An implementation of one or more FIRME services at a valid Exception level boundary between EL3 and the
> highest Exception level in a different Security state is called a FIRME instance.
>
> and I think only NS-EL2 can call FIRME interfaces as a NS FIRME
> instance, right?
Yeap. but it doens't forbid calling the FIRME from EL1 too.
As a just example, when the host running with pkvm, it could use
where kernel running as EL1.
[...]
--
Sincerely,
Yeoreum Yun
next prev parent reply other threads:[~2026-10-22 13:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:14 [PATCH RFC 0/3] firmware: arm_firme: introduce FIRME support for host attestation Yeoreum Yun
2026-10-19 14:14 ` [PATCH RFC 1/3] firmware: arm_firme: introduce arm_firme driver Yeoreum Yun
2026-10-22 9:48 ` Kohei Enju
2026-10-22 13:17 ` Yeoreum Yun [this message]
2026-10-23 5:48 ` Kohei Enju
2026-10-19 14:14 ` [PATCH RFC 2/3] firmware: arm-smccc: add FIRME device Yeoreum Yun
2026-10-19 14:14 ` [PATCH RFC 3/3] firmware: arm-firme: TSM_REPORT support using FIRME Yeoreum Yun
2026-10-19 23:35 ` [PATCH RFC 0/3] firmware: arm_firme: introduce FIRME support for host attestation Jason Gunthorpe
2026-10-20 7:13 ` Yeoreum Yun
2026-10-20 12:45 ` Jason Gunthorpe
2026-10-20 13:41 ` Yeoreum Yun
2026-10-20 13:50 ` Jason Gunthorpe
2026-10-20 14:13 ` Yeoreum Yun
2026-10-20 14:36 ` Jason Gunthorpe
2026-10-20 14:43 ` Yeoreum Yun
2026-10-20 14:58 ` Jason Gunthorpe
2026-10-20 15:18 ` Yeoreum Yun
2026-10-20 16:47 ` Jason Gunthorpe
2026-10-20 17:05 ` Yeoreum Yun
2026-10-20 18:47 ` Jason Gunthorpe
2026-10-20 19:27 ` Yeoreum Yun
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=atoM447tWm2EsoSP@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=enju.kohei@fujitsu.com \
--cc=gongruiqi1@huawei.com \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=sami.mujawar@arm.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.