[RFC] OpenSBI per-domain handling for FWFT LANDING_PAD / menvcfg.LPE

Raymond Mao raymondmaoca at gmail.com
Fri Oct 16 08:38:44 PDT 2026


Hi Anup and all,

As part of RISE RP022, I am working on adding RISC-V Zicfilp landing-pad
support to OP-TEE.

For OP-TEE running in S-mode, enabling Zicfilp enforcement requires the
SBI Firmware Features (FWFT) LANDING_PAD feature, which controls
menvcfg.LPE for the calling supervisor.

During review of the OP-TEE RFC, Robin identified a possible issue with
domain coexistence.

As we understand the current OpenSBI implementation, the FWFT LANDING_PAD
state and menvcfg.LPE are effectively maintained per hart rather than
per domain. Although the domain context switch already preserves state
such as sstatus and senvcfg, menvcfg.LPE does not appear to be part of
the per-domain context.

If menvcfg.LPE is not switched together with the OpenSBI domain,
enabling Zicfilp for one S-mode domain could unintentionally leave it
enabled for another S-mode domain running later on the same hart. For
example, an uninstrumented Linux kernel could inherit landing-pad
enforcement enabled by an OP-TEE domain and fault on an indirect branch.
The reverse situation could also occur.

Could you please confirm whether this understanding of the current
OpenSBI behavior is correct, and whether per-domain handling of the
FWFT LANDING_PAD / menvcfg.LPE state would be needed?

I am mainly raising this here to highlight the dependency before the
OP-TEE S-mode Zicfilp enablement work progresses further.

The OP-TEE RFC is being tracked here:
https://lists.riseproject.dev/g/platform-wg/topic/121789281
https://github.com/OP-TEE/optee_os/issues/8096

Thanks and regards,
Raymond



More information about the opensbi mailing list