"Session ID: BUD17-510 Session Name: Power management in Linux together with secure firmware - BUD17-510 Speaker: Vincent Guittot, Joakim Bech Track: Security ★ Session Summary ★ On a device it’s not uncommon to share power domains between secure and non-secure side, for example between a TEE and Linux kernel. With that comes some challenges that needs to be taken care of and that is the theme for this presentation. We’ve identified a couple of challenges when it comes to power management and security. One case is when sharing power resources (clock, power domains, ...) between secure and non-secure devices. Another is to make a proper shutdown and boot-up sequence (CPU on/off etc) and finally there has been some concerns regarding the latency when communicating with PSCI. In this session we would like to highlight those and discuss what the short and long term plans are. --------------------------------------------------- ★ Resources ★ Event Page: http://connect.linaro.org/resource/bud17/bud17-510/ Presentation: https://www.slideshare.net/linaroorg/bud17510-power-management-in-linux-together-with-secure-firmware Video: https://youtu.be/MNvTBGNQRDY --------------------------------------------------- ★ Event Details ★ Linaro Connect Budapest 2017 (BUD17) 6-10 March 2017 Corinthia Hotel, Budapest, Erzsébet krt. 43-49, 1073 Hungary --------------------------------------------------- Keyword: security, power-management, linux http://www.linaro.org http://connect.linaro.org --------------------------------------------------- Follow us on Social Media https://www.facebook.com/LinaroOrg https://twitter.com/linaroorg https://www.youtube.com/user/linaroorg?sub_confirmation=1 https://www.linkedin.com/company/1026961"

1. Power management in Linux together
with secure firmware
Joakim Bech and Vincent Guittot

2. ENGINEERS
AND DEVICES
WORKING
TOGETHER
An environment with shared resources
● Linux is (usually) the main component controlling devices
○ Clocks
○ Power Domains
○ Hardware IP
○ etc ...
● Secure side firmware also controls and uses components
○ Crypto blocks
○ Perhipherals
○ External cache maintenance
● Secure side directly controls a few things
○ PSCI

3. ENGINEERS
AND DEVICES
WORKING
TOGETHER
Crypto hardware blocks
● It’s not uncommon that crypto hardware blocks are
shared between normal and secure world
● Without proper synchronization, things can go really
wrong, example:
○ Secure side does a crypto job and normal world decides to turn off
the block
○ Both normal and secure side tries to use the crypto block at the
same time
● I.e., if the hardware itself cannot handle multiple sources,
then there is a need for some kind of synchronization
primitive shared between secure and non-secure world

4. ENGINEERS
AND DEVICES
WORKING
TOGETHER
CPU Latency
● Using PSCI (secure side) is mandatory on ARMv8-A
● Latency for powering up and down CPU/clusters have
increased compared to previous architectures
○ The addition of switching and running code in secure side also
seems to have added a significant cost in terms of latency
● Ongoing effort to consolidate CPU idle state decision into
the scheduler
● Some state doesn’t need any save of the context
○ Like CPU retention or Cluster retention

5. ENGINEERS
AND DEVICES
WORKING
TOGETHER
● Manage shared power resources between secure and non
secure devices
● Non secure side
○ Secure world interaction for every device state change is not efficient
○ power domain can consolidate non secure state
● Secure side
○ Can’t trust non secure world
power domain 0
Device Latency
Device
B
Device
A
Device
D
Device
C
Secure Non secure
clock X
Device
F
Device
E

6. ENGINEERS
AND DEVICES
WORKING
TOGETHER
Suspend to RAM - done right
1. ARM recommends:
1.1. REE saves states, REE transitions to TEE, TEE saves states
1.2. TEE communicates with PMIC to put the device into low power
standby
2. Partners to users of OP-TEE reported that they often see:
2.1. REE saves states, REE transitions to TEE, TEE saves states
2.2. TEE transitions back to REE
2.3. REE communicates with PMIC to put the device into low power
standby
● I.e., REE PMIC bypass the TEE => (Usually) not good!
○ This can lead to memory protected by the TEE can become available
to the REE
○ There is a also a risk of corrupting TEE states
● Partners expressed wishes that TEE’s supports both TEE
and REE controlled PMIC flow.

7. Thank You
#BUD17
For further information: www.linaro.org
BUD17 keynotes and videos on: connect.linaro.org
joakim.bech@linaro.org and vincent.guittot@linaro.org