• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 351 subscribers
  • Views 7398 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex-A9: disable SIMD, Neon & VFP in the secure world

Vincent Siles

Hi ! I'm trying to configure my secure monitor so that:

- the secure world does not have access to any floating-point hardware

- the normal world can do whatever it wants

 

To this purpose, I allow the normal world to use the relevant registers by configuring CPACR and NSACR.

In order to prevent the Secure world to use the relevant registers & operation, I want to:

- when switching from NS -> S: save the value of FPEXC, and set FPEXC[EN] to 0

- when switchting from S -> NS: restoring the value of FPEXC

 

Will this be enough to prevent any fp operation in the Secure world, while allowing a normal usage in the NW ?

 

Best,

V.

Parents
  • 0 Arm Employee Badge
    Hi,

    You are spot on. Setting FPEXC.EN==0 in the secure monitor will cause any VFP or SIMD instructions to undef until you re-enable it.

    Note that as monitor mode and the other secure PL1 modes share the same level of privilege there is no way to stop a secure kernel re-enabling VFP but the nature of the trust model means you have to trust the kernel to play nicely.

    On a v8-A platform the monitor runs at a higher level of privilege than the trusted kernel (EL3 vs S-EL1) and there are trap registers that can stop secure EL1 re-enabling FP.

    Pete.
Reply
  • 0 Arm Employee Badge
    Hi,

    You are spot on. Setting FPEXC.EN==0 in the secure monitor will cause any VFP or SIMD instructions to undef until you re-enable it.

    Note that as monitor mode and the other secure PL1 modes share the same level of privilege there is no way to stop a secure kernel re-enabling VFP but the nature of the trust model means you have to trust the kernel to play nicely.

    On a v8-A platform the monitor runs at a higher level of privilege than the trusted kernel (EL3 vs S-EL1) and there are trap registers that can stop secure EL1 re-enabling FP.

    Pete.
Children
  • 0 in reply to Peter Rielly
    Ok, thanks ! I'm quite new to floating point so I also wonder: what about NEON ? (you only wrote about VFP and SIMD)
  • +1 Arm Employee Badge in reply to Vincent Siles
    The naming is a bit confusing.

    ARMv6 introduced a handful of SIMD instructions that used the regular register bank. ARMv7-A introduced "Advanced SIMD" which had a load more instructions and used the expanded VFP register bank.

    In ARMv8-A AArch64 there are SIMD instruction that use the FP register bank, but they are not advanced anymore, just plain SIMD.

    NEON is the 'marketing' name for the ARM implementation of the Advanced SIMD instructions. So an ARM CPU (ie Cortex-A-somthing) will have a NEON unit but a CPU from an architecture licencee will have a SIMD unit that executes the same instructions but it will not be called NEON.

    Clear :)

    There is a separate enable for NEON in CPACR.ASEDIS which you could also toggle but all the NEON instructions require VFP to be enabled anyway. So FPEXC.EN should be enough.

    Pete.