Introducing today’s webinar subject
● Trusted Execution Environment - a software
isolation environment for executing security
applications
● Work originally on ARM TrustZone(R) technology
for hardware isolation between the trusted and
non-trusted worlds (see the diagram on the left)
● An open source project op-tee.org/about/
● The driver source for the TEE has been recently
accepted upstream for the 4.12 Linux kernel
Who is this webinar for?
● Members of the development community:
○ developing secure applications under Linux
○ contributing to open source
○ working in the ARM ecosystem
○ interested in upstreaming
○ anyone with supported hardware
What we’ll cover in this webinar
● A backgrounder on
○ OP-TEE
○ the components that make it up
○ the design principles behind it
● Why it’s important
● How the code got upstream
● How to get involved
We welcome your questions!
● There will be a Q&A at the end of the presentation. You can raise a question at
any time as we go along in the chat window.
● We’ll try to answer as many questions as we can at the end of the presentation
● It’s useful to us if you can click on the dropdown speech bubble next to the chat
for your comment to ‘Mark as a question’
How to mark your chat comment as a question
Today’s Presenters
● Joakim Bech
● Security Expert
● Bill Fletcher
● Moderator
● Jens Wiklander
● Security Working Group
Senior Engineer &
Upstream Driver Author
TEE - kernel support is now upstream.
What this means for open source
security
Joakim Bech
OP-TEE
What is OP-TEE?
2010 2013 2014 2015
GP compliance!
OP-TEE
● Open Portable Trusted Execution Environment
● Open Source and GlobalPlatform based TEE
● Origins from ST-Ericsson / STMicroelectronics proprietary TEE
○ Used in NovaThor products (mainly U8500)
● Linaro owns and maintains OP-TEE since 2015.
Ownership from
STM to Linaro
Where does OP-TEE run?
● ARMv7-A (32bit)
● ARMv8-A (64/32bit)
● Development devices
○ ARM Juno board, RPi3, HiKey etc.
● Consumer products
○ Tablets, mobile phones, set-top boxes, cars
● In OP-TEE upstream +20 platforms are officially
supported.
○ We are aware of quite a few vendors using OP-TEE, but
their platform is still not found in the upstream tree
for one or another reason.
GlobalPlatform compliance / qualification?
● The software itself cannot be tested for compliance, it is always a combination
of software + hardware that is tested
● To support the Self Testing and Product Qualification Processes,
GlobalPlatform has developed a GlobalPlatform Test Suite
Proprietary era Open Source era
2010 2014 2017
ST-Ericsson based devices
passed compliance test
Decision by individual
companies
Some members of Linaro runs the
GP test suite on regular basis!
OP-TEE components
Normal World Secure World
User space
optee_client
optee_test
Linux kernel
TEE framework +
OP-TEE driver
Secure user space
Trusted Applications
(like optee_test)
Secure privileged
mode
optee_os
Secure Monitor
v7-A: optee_os
v8-A: ARM-TF
This is what we
are going to
talk about
today!
TEE Generic Framework
Linux kernel v4.12
Why a TEE framework in kernel?
● Linux kernel is everywhere, from tiny
devices to industrial systems
● Source code has been scrutinized
○ Kernel maintainers are very honest experts
and not as “nice” as your corporate friend
sitting next to you in the office
○ As a result of that the code actually being
merged generally keeps a high standard
● Maintenance for “free”
● SoC vendors and OEM prefer pulling
(official) patches from a single tree
● Use cases? Only DRM? No!
● It’s about unifying TEE protocols!
Image courtesy of xkcd.com https://imgs.xkcd.com/comics/supported_features.png
GlobalPlatform? What is their role in the TEE driver
● Is the TEE driver in kernel a GlobalPlatform TEE driver?
○ A TEE driver uses a generic TEE framework, i.e., not tied to GP interfaces
● GlobalPlatform specifications define APIs for the end points ...
○ Client in Normal World - GP Client API specification
○ Trusted Applications in Secure World - GP Internal Core API specification
● … but does not mandate how layers in between shall handle the data
Secure world Normal world
Trusted app TEE core Linux kernel Client
GlobalPlatform GlobalPlatform
Generic TEE
driver
Vendor
specific
● So the answer is, not much, but ideas etc are definitely inherited!
● But OP-TEE is a GlobalPlatform TEE, right?
Generic TEE Framework - design principles
● Keep it small and simple
○ A small set of IOCTL’s
■ include/uapi/linux/tee.h
■ static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
● The data being transferred is opaque to the driver itself
● Use existing infrastructure in kernel
● Multi-core support
● A TEE driver uses the new framework
○ TEE Generic Framework ...
○ … is used by a TEE Vendor to implement a driver for their TEE solution
○ Currently only OP-TEE uses this new framework
IOCTL’s - Version
● TEE_IOC_VERSION
○ Identifies the TEE implementation
○ Query the TEE for specific features
○ Eventually used when there is more than one (?) TEE implementation on the system
● OP-TEE example:
struct tee_ioctl_version_data v = {
.impl_id = TEE_IMPL_ID_OPTEE,
.impl_caps = TEE_OPTEE_CAP_TZ,
.gen_caps = TEE_GEN_CAP_GP,
};
TEE is OP-TEE
OP-TEE capabilities
Generic capabilities: GlobalPlatform
● TEE_IOC_OPEN_SESSION
○ The command that opens a communication channel between the client and the Trusted
Application.
● TEE_IOC_CLOSE_SESSION
○ Closes an open session
IOCTL’s - Sessions
User space
Linux kernel
Trusted Applications
Secure OS
Secure Monitor
Communication channel
IOCTL’s - Commands
● TEE_IOC_CANCEL
○ The command that gives the users the ability to cancel an ongoing operation.
● TEE_IOC_INVOKE
○ The main command to invoke commands that in turn will run Trusted Application specific
functionality.
○ The principle is to use a unique Trusted Application command identifier together with data we
are working with.
● Some out of TEE drivers out there have very specific commands for various use
cases. Such drivers would need to change this behavior to instead “tunnel” all
the data in invoke command.
○ Trustonic-tee-driver: 17
○ QSEE: +30
IOCTL’s - Supplicants
● TEE_IOC_SUPPL_RECV
● TEE_IOC_SUPPL_SEND
● A supplicant is typically a daemon running in normal world
○ Serves secure side with various services
■ File system access
■ RPMB
■ REE time
■ etc
● We believe most TEE vendors have some kind of supplicant to support their TEE
Probe function
● As for drivers in general, we need a probe function
● Example, OP-TEE’s probe function
○ static struct optee *optee_probe(struct device_node *np)
■ Get the invoke function (SMC or HVC?)
■ Check UUID and revision
■ Check capabilities
■ Configure shared memory
■ Allocate TEE device(s) - both for the
client(s) and for the supplicant
● The probe will not be called if there is
no firmware section in the Device
Tree blob
Challenges upstreaming a TEE Framework
● There are many kernel experts, but not that many of them are security experts
○ TEE driver is just one part of the entire TEE solution
● Getting people to review
○ Corporate policies
○ Unawareness of how to communicate on kernel mailinglists
● Chicken and egg problem
○ Keep patchsets small (submit early, submit often mentality)
○ But there must be enough to prove that it is actually working
● Other features being developed while doing upstream
○ Kernel TEE interface (GlobalPlatform Client API like), Secure Data Path, Benchmarking etc.
● Getting enough input from other TEE vendors
How to contribute?
● New to TEE development?
○ Study and try the driver with OP-TEE for example.
● TEE vendor?
○ Give feedback on the Linux kernel mailinglists about the current driver
○ (Try to) rewrite your current driver to use the new generic TEE framework
● Review patches!
● Talk to Linaro directly or?
○ For OP-TEE related questions and discussions: Yes!
○ For generic TEE framework discussions? No! Use the Linux kernel mailinglists.
● Subscribe to the mailinglists
○ linux-arm-kernel@lists.infradead.org
○ linux-kernel@vger.kernel.org
What does all this mean to Open Source Security?
● Another step in trying to unify TEE protocols
○ As mentioned, GlobalPlatform has defined the endpoints in the communication channel, but
nothing has been defined between the endpoints!
● Reduce fragmentation
○ Many other subsystems share common frameworks in Linux
○ TEE implementations should be able to do that too!
● A common code base
○ Regardless what TEE we are working with, we have a common source code repository (if we
want to…)
We welcome your questions!
● Next up -the Q&A. You can raise a question in the chat window.
● We’ll try to answer as many questions as we can at the end of the presentation
● It’s useful to us if you can click on the dropdown speech bubble next to the chat
for your comment to ‘Mark as a question’
How to mark your chat comment as a question
LEADING COLLABORATION
IN THE ARM ECOSYSTEM
About Linaro
● Linaro delivers engineering effort to develop key technologies for the ARM
ecosystem
● Linaro develops lots of key software technologies:
○ Tools and Languages, Firmware, Security, Virtualization, Power Management
○ Technology enablers for Mobile, Server, Multimedia, Networking and Embedded/IoT segments
● Linaro delivers its output to its members, into open source projects, and into the
community. Check out our websites and projects which we host or support:
○ linaro.org/downloads, linaro.cloud
○ 96boards.org, op-tee.org, opendataplane.org,
○ kernelci.org
● Linaro works with its members to maximize the return on their open source
investment
We welcome your questions!
● It’s the Q&A. You can raise a question in the chat window.
● If we run out of time we’ll try to follow up any remaining questions by mail
● It’s useful to us if you can click on the dropdown speech bubble next to the chat
for your comment to ‘Mark as a question’
How to mark your chat comment as a question
Thank You
For further information:
Linaro.org and OP-TEE.org

TEE - kernel support is now upstream. What this means for open source security

  • 2.
    Introducing today’s webinarsubject ● Trusted Execution Environment - a software isolation environment for executing security applications ● Work originally on ARM TrustZone(R) technology for hardware isolation between the trusted and non-trusted worlds (see the diagram on the left) ● An open source project op-tee.org/about/ ● The driver source for the TEE has been recently accepted upstream for the 4.12 Linux kernel
  • 3.
    Who is thiswebinar for? ● Members of the development community: ○ developing secure applications under Linux ○ contributing to open source ○ working in the ARM ecosystem ○ interested in upstreaming ○ anyone with supported hardware
  • 4.
    What we’ll coverin this webinar ● A backgrounder on ○ OP-TEE ○ the components that make it up ○ the design principles behind it ● Why it’s important ● How the code got upstream ● How to get involved
  • 5.
    We welcome yourquestions! ● There will be a Q&A at the end of the presentation. You can raise a question at any time as we go along in the chat window. ● We’ll try to answer as many questions as we can at the end of the presentation ● It’s useful to us if you can click on the dropdown speech bubble next to the chat for your comment to ‘Mark as a question’ How to mark your chat comment as a question
  • 6.
    Today’s Presenters ● JoakimBech ● Security Expert ● Bill Fletcher ● Moderator ● Jens Wiklander ● Security Working Group Senior Engineer & Upstream Driver Author
  • 7.
    TEE - kernelsupport is now upstream. What this means for open source security Joakim Bech
  • 8.
  • 9.
    What is OP-TEE? 20102013 2014 2015 GP compliance! OP-TEE ● Open Portable Trusted Execution Environment ● Open Source and GlobalPlatform based TEE ● Origins from ST-Ericsson / STMicroelectronics proprietary TEE ○ Used in NovaThor products (mainly U8500) ● Linaro owns and maintains OP-TEE since 2015. Ownership from STM to Linaro
  • 10.
    Where does OP-TEErun? ● ARMv7-A (32bit) ● ARMv8-A (64/32bit) ● Development devices ○ ARM Juno board, RPi3, HiKey etc. ● Consumer products ○ Tablets, mobile phones, set-top boxes, cars ● In OP-TEE upstream +20 platforms are officially supported. ○ We are aware of quite a few vendors using OP-TEE, but their platform is still not found in the upstream tree for one or another reason.
  • 11.
    GlobalPlatform compliance /qualification? ● The software itself cannot be tested for compliance, it is always a combination of software + hardware that is tested ● To support the Self Testing and Product Qualification Processes, GlobalPlatform has developed a GlobalPlatform Test Suite Proprietary era Open Source era 2010 2014 2017 ST-Ericsson based devices passed compliance test Decision by individual companies Some members of Linaro runs the GP test suite on regular basis!
  • 12.
    OP-TEE components Normal WorldSecure World User space optee_client optee_test Linux kernel TEE framework + OP-TEE driver Secure user space Trusted Applications (like optee_test) Secure privileged mode optee_os Secure Monitor v7-A: optee_os v8-A: ARM-TF This is what we are going to talk about today!
  • 13.
  • 14.
    Why a TEEframework in kernel? ● Linux kernel is everywhere, from tiny devices to industrial systems ● Source code has been scrutinized ○ Kernel maintainers are very honest experts and not as “nice” as your corporate friend sitting next to you in the office ○ As a result of that the code actually being merged generally keeps a high standard ● Maintenance for “free” ● SoC vendors and OEM prefer pulling (official) patches from a single tree ● Use cases? Only DRM? No! ● It’s about unifying TEE protocols! Image courtesy of xkcd.com https://imgs.xkcd.com/comics/supported_features.png
  • 15.
    GlobalPlatform? What istheir role in the TEE driver ● Is the TEE driver in kernel a GlobalPlatform TEE driver? ○ A TEE driver uses a generic TEE framework, i.e., not tied to GP interfaces ● GlobalPlatform specifications define APIs for the end points ... ○ Client in Normal World - GP Client API specification ○ Trusted Applications in Secure World - GP Internal Core API specification ● … but does not mandate how layers in between shall handle the data Secure world Normal world Trusted app TEE core Linux kernel Client GlobalPlatform GlobalPlatform Generic TEE driver Vendor specific ● So the answer is, not much, but ideas etc are definitely inherited! ● But OP-TEE is a GlobalPlatform TEE, right?
  • 16.
    Generic TEE Framework- design principles ● Keep it small and simple ○ A small set of IOCTL’s ■ include/uapi/linux/tee.h ■ static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) ● The data being transferred is opaque to the driver itself ● Use existing infrastructure in kernel ● Multi-core support ● A TEE driver uses the new framework ○ TEE Generic Framework ... ○ … is used by a TEE Vendor to implement a driver for their TEE solution ○ Currently only OP-TEE uses this new framework
  • 17.
    IOCTL’s - Version ●TEE_IOC_VERSION ○ Identifies the TEE implementation ○ Query the TEE for specific features ○ Eventually used when there is more than one (?) TEE implementation on the system ● OP-TEE example: struct tee_ioctl_version_data v = { .impl_id = TEE_IMPL_ID_OPTEE, .impl_caps = TEE_OPTEE_CAP_TZ, .gen_caps = TEE_GEN_CAP_GP, }; TEE is OP-TEE OP-TEE capabilities Generic capabilities: GlobalPlatform
  • 18.
    ● TEE_IOC_OPEN_SESSION ○ Thecommand that opens a communication channel between the client and the Trusted Application. ● TEE_IOC_CLOSE_SESSION ○ Closes an open session IOCTL’s - Sessions User space Linux kernel Trusted Applications Secure OS Secure Monitor Communication channel
  • 19.
    IOCTL’s - Commands ●TEE_IOC_CANCEL ○ The command that gives the users the ability to cancel an ongoing operation. ● TEE_IOC_INVOKE ○ The main command to invoke commands that in turn will run Trusted Application specific functionality. ○ The principle is to use a unique Trusted Application command identifier together with data we are working with. ● Some out of TEE drivers out there have very specific commands for various use cases. Such drivers would need to change this behavior to instead “tunnel” all the data in invoke command. ○ Trustonic-tee-driver: 17 ○ QSEE: +30
  • 20.
    IOCTL’s - Supplicants ●TEE_IOC_SUPPL_RECV ● TEE_IOC_SUPPL_SEND ● A supplicant is typically a daemon running in normal world ○ Serves secure side with various services ■ File system access ■ RPMB ■ REE time ■ etc ● We believe most TEE vendors have some kind of supplicant to support their TEE
  • 21.
    Probe function ● Asfor drivers in general, we need a probe function ● Example, OP-TEE’s probe function ○ static struct optee *optee_probe(struct device_node *np) ■ Get the invoke function (SMC or HVC?) ■ Check UUID and revision ■ Check capabilities ■ Configure shared memory ■ Allocate TEE device(s) - both for the client(s) and for the supplicant ● The probe will not be called if there is no firmware section in the Device Tree blob
  • 22.
    Challenges upstreaming aTEE Framework ● There are many kernel experts, but not that many of them are security experts ○ TEE driver is just one part of the entire TEE solution ● Getting people to review ○ Corporate policies ○ Unawareness of how to communicate on kernel mailinglists ● Chicken and egg problem ○ Keep patchsets small (submit early, submit often mentality) ○ But there must be enough to prove that it is actually working ● Other features being developed while doing upstream ○ Kernel TEE interface (GlobalPlatform Client API like), Secure Data Path, Benchmarking etc. ● Getting enough input from other TEE vendors
  • 23.
    How to contribute? ●New to TEE development? ○ Study and try the driver with OP-TEE for example. ● TEE vendor? ○ Give feedback on the Linux kernel mailinglists about the current driver ○ (Try to) rewrite your current driver to use the new generic TEE framework ● Review patches! ● Talk to Linaro directly or? ○ For OP-TEE related questions and discussions: Yes! ○ For generic TEE framework discussions? No! Use the Linux kernel mailinglists. ● Subscribe to the mailinglists ○ linux-arm-kernel@lists.infradead.org ○ linux-kernel@vger.kernel.org
  • 24.
    What does allthis mean to Open Source Security? ● Another step in trying to unify TEE protocols ○ As mentioned, GlobalPlatform has defined the endpoints in the communication channel, but nothing has been defined between the endpoints! ● Reduce fragmentation ○ Many other subsystems share common frameworks in Linux ○ TEE implementations should be able to do that too! ● A common code base ○ Regardless what TEE we are working with, we have a common source code repository (if we want to…)
  • 25.
    We welcome yourquestions! ● Next up -the Q&A. You can raise a question in the chat window. ● We’ll try to answer as many questions as we can at the end of the presentation ● It’s useful to us if you can click on the dropdown speech bubble next to the chat for your comment to ‘Mark as a question’ How to mark your chat comment as a question
  • 26.
    LEADING COLLABORATION IN THEARM ECOSYSTEM About Linaro ● Linaro delivers engineering effort to develop key technologies for the ARM ecosystem ● Linaro develops lots of key software technologies: ○ Tools and Languages, Firmware, Security, Virtualization, Power Management ○ Technology enablers for Mobile, Server, Multimedia, Networking and Embedded/IoT segments ● Linaro delivers its output to its members, into open source projects, and into the community. Check out our websites and projects which we host or support: ○ linaro.org/downloads, linaro.cloud ○ 96boards.org, op-tee.org, opendataplane.org, ○ kernelci.org ● Linaro works with its members to maximize the return on their open source investment
  • 27.
    We welcome yourquestions! ● It’s the Q&A. You can raise a question in the chat window. ● If we run out of time we’ll try to follow up any remaining questions by mail ● It’s useful to us if you can click on the dropdown speech bubble next to the chat for your comment to ‘Mark as a question’ How to mark your chat comment as a question
  • 28.
    Thank You For furtherinformation: Linaro.org and OP-TEE.org