4

On an ARM Cortex A9 core, privileged instructions have to be executed so that unprivileged code can use performance counters. For instance with this GCC inline code, which would have to be run in a kernel:

/* Allow access to perf counter */
__asm__ __volatile__ ("\tMCR p15, 0, %0, C9, C14, 0\n" :: "r" (1));

/* Turn off counter overflow interrupts */
__asm__ __volatile__ ("\tMCR p15, 0, %0, C9, C14, 2\n" :: "r" (0x8000000f));

If access is not enabled, then user programs which try to access the cycle counter receive an "illegal instruction" exception, and of course user programs cannot run the enable sequence.

My question is, is there some security reason for protecting the counters?

All I can think of is that in a trusted computing type environment, unprivileged code could obtain very precise timing information about calls to some security sensitive code.

I want to get as much information as I can before adding such code to the startup code of a kernel that customers will integrate into end products which have tight security requirements.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
Kaz
  • 2,303
  • 16
  • 17

1 Answers1

5

Very precise timing information is very helpful when doing side-channel attacks. Some famous example (in lab conditions) include stealing an encryption key used by some other process, on data we do not see (neither cleartext nor ciphertext). This can work on detection of L1 cache misses, or of jump (mis)prediction in the CPU. Forbidding access to the cycle counter will make such attacks harder (not impossible, but harder).

If you do not have concurrent processes potentially hostile to each other, running on the same CPU (a scenario which includes the case of two distinct virtual machines which share the same hardware), then there is little reason to deactivate the cycle counter.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475