You copied the Doc URL to your clipboard.

How is a Secure Physical Timer accessed in Armv8-A?

Article ID: 129928921

Published date: 13 Feb 2018

Last updated: -

Applies to: ARMv8-A

Problem/Question

How is a Secure Physical Timer accessed in Armv8-A?

Scenario

Armv8-A describes the implementation of the Arm Generic Timer, which can schedule events and trigger interrupts based on incrementing counter values. In an implementation of the Generic Timer that includes EL3, the following timers are implemented:

  • A Non-secure EL1 Physical Timer.

  • A Non-secure EL2 Physical Timer.

  • A Secure EL3 Physical Timer.

  • A Virtual Timer.

Generally, a Rich operating system (OS) uses the EL1 Non-secure Physical Timer, and a Trusted OS uses the Secure Physical Timer. For example:

  • If EL3, NS-EL1, and S-EL1 use AArch64, there are separate Physical Timer registers for Secure and Non-secure worlds.

o A Rich OS uses the CNTP_CVAL_EL0 register, the CNTP_TVAL_EL0 , and the CNTP_CTL_EL0 registers.

o A Trusted OS uses the CNTPS_CVAL_EL1 register, the CNTPS_TVAL_EL1 register, and the CNTPS_CTL_EL1 register.

  • If EL3 uses AArch32, the Secure and Non-secure Physical Timer registers are banked.

o A Rich OS uses the Non-secure banked instances of the CNTP_CTL register, the CNTP_CVAL register, and the CNTP_TVAL register.

o A Trusted OS uses the Secure instances of the same registers.

The problem is that, if EL3 uses AArch64 and S-EL1 uses AArch32, then S-EL1 cannot access the Secure Physical Timer registers directly. In this case, how can the Secure Physical Timer be accessed?

Answer

Reason

Armv8-A architecturally defines the relationship between the AArch64 System Registers and the AArch32 System Registers. This allows supervisory code, such as a Secure Monitor that executes in AArch64 state, to save, restore, and interpret the System registers belonging to a lower Exception level that uses AArch32.

When EL3 is implemented and uses AArch32, some System Registers are banked between the two Security states. When a register is banked this way, there is an instance of the register in Secure state, and another instance of the register in Non-secure state. However, the register banking is not supported when EL3 uses AArch64. When a lower exception level uses AArch32, it is architecturally not possible to determine whether an AArch64 register is mapped onto the Secure instance of the corresponding AArch32 register, or onto the Non-secure instance of that register.

If EL3 uses AArch64 and S-EL1 uses AArch32, then the AArch32 System registers CNTP_* are architecturally mapped to AArch64 System registers CNTP_*. In other words, a Trusted OS cannot access the Secure Physical Timer registers directly.

Solution

You can resolve this problem by using one of the following methods:

  • Porting the Trusted OS to AArch64. If a Trusted OS runs in AArch64 at S-EL1, it can access the Secure timer registers.

  • EL3 can access the Secure Timer. Therefore, you can develop a Secure Timer service in EL3 to provide atomic SMC operations that allow the Trusted OS to program the Secure Physical Timer registers.

  • Timer registers are architecturally mapped to AArch64 Non-secure Physical Timer registers. If a Trusted OS uses the Physical Timer in Secure EL1, EL3 software must save and restore the Non-secure Physical Timer registers when switching context, and change the Non-secure Physical Timer interrupt into Secure groups.

  • If the System on Chip (SoC) has an external Secure Timer, a Trusted OS can use the external Secure Timer.

Workaround

N/A

Example

N/A

Related Information

N/A

Was this page helpful? Yes No