Hi Olivier,

On Wed, Apr 13, 2022 at 3:45 PM Olivier Deprez Olivier.Deprez@arm.com wrote:

Hi Jens,

We ran in a similar situation with Hafnium. ID registers reflect what the HW really implements, here qemu reports MTE arch ext. is implemented in HW. EL3 doesn't have the ability to alter ID registers for lower ELs consumption, and OP-TEE reads the physical registers. So indeed IMO there is no better way than always providing the TF-A build option.

It's just that TF-A doesn't check id_aa64pfr1_el1 is MTE is available if compiled with CTX_INCLUDE_MTE_REGS. If the MTE isn't supported by the CPU then there's a crash during early boot. This isn't much of a problem on physical hardware, but in an emulator such as QEMU it can add a bit of extra work to keep everything in sync.

Side note, in context of Hafnium ID registers are virtualized and I expect OP-TEE can rely on ID reg to determine if safe to access the feature.

That's good to know.

Thanks, Jens

Regards, Olivier.

---

From: Jens Wiklander via TF-A tf-a@lists.trustedfirmware.org Sent: 13 April 2022 15:21 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] MTE support at S-EL1

Hi,

I've started to experiment with MTE in OP-TEE at S-EL1. I've compiled TF-A with CTX_INCLUDE_MTE_REGS and I'm testing this on QEMU. Before trying to use MTE in OP-TEE I check id_aa64pfr1_el1 and skip MTE initializations if unavailable.

This works as long as TF-A always is compiled with CTX_INCLUDE_MTE_REGS if MTE is available. If TF-A is compiled without CTX_INCLUDE_MTE_REGS OP-TEE will be trapped into EL3 when trying to access one of the MTE registers. I suppose this is because SCR_EL3.ATA is 0. Is there a way for OP-TEE to tell if the MTE registers are safe to access?

Thanks, Jens -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org