\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}% http://ctan.org/pkg/lm
\usepackage{minted}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{pgfplots}
\usepackage{tikz}
\usepackage[normalem]{ulem}


\mode<presentation>
\usetheme{Bootlin}

\def\signed #1{{\leavevmode\unskip\nobreak\hfil\penalty50\hskip2em
  \hbox{}\nobreak\hfil(#1)
  \parfillskip=0pt \finalhyphendemerits=0 \endgraf}}

\graphicspath{ {./graphics/} }

\newsavebox\mybox
\newenvironment{aquote}[1]
  {\savebox\mybox{#1}\begin{quotation}}
  {\signed{\usebox\mybox}\end{quotation}}

\title{OP-TEE: When Linux Loses Control}
\authors{Clément Léger}
\email{clement.leger@bootlin.com}
\slidesurl{https://bootlin.com/pub/conferences/2021}
\institute{Bootlin}
\conference{Embedded Linux Conference, September 27th 2021}

\begin{document}

\addtocontents{toc}{\protect\setcounter{tocdepth}{-1}}
\section{OP-TEE: When Linux Loses Control}
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}}

\begin{frame}{Clément Léger}
  \begin{itemize}
  \item Embedded Linux engineer at Bootlin
  \begin{itemize}
    \item Embedded Linux {\bf expertise}
    \item Low-level development for Linux kernel, Bootloader, etc
    \item {\bf Development}, consulting and training
    \item Strong open-source focus
  \end{itemize}
  \item Ported Linux to a custom VLIW architecture
  \item Living in {\bf Grenoble}, near the Alps in France
  \end{itemize}
\end{frame}
 
\begin{frame}{About this talk}
  \begin{itemize}
  \item Explain what is OP-TEE
  \item Explain OP-TEE integration into an existing system which runs everything in secure mode
  \item Describe interactions between various components (SPL/OP-TEE/Bootloader/Linux)
  \item Present various protocols \& methods to communicate between REE/TEE (SCMI, PSCI, SMC)
  \item Provide experience feedback on Microchip SAMA5D2 OP-TEE port (ARMv7-A)
  \end{itemize}
\end{frame}

\begin{frame}{What is OP-TEE ?}
  \center \includegraphics[width=0.1\textwidth]{optee_logo.png}
  \begin{itemize}
    \item \textbf{O}pen \textbf{P}ortable \textbf{T}rusted \textbf{E}xecution \textbf{E}nvironment
    \item Provides secure services to a Rich Execution Environment (\textbf{REE}) (Typically Linux).
    \item Based on hardware-enforced isolation technology (ARM TrustZone)
    \item Secure Monitor Calls (\textbf{SMC} instruction) allow to switch REE $\leftrightarrow$ TEE via the secure monitor
    \begin{itemize}
      \item Much like a SVC but jump to a higher privileged mode (Monitor).
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{TrustZone}
  \center \includegraphics[width=0.6\textwidth]{trustzone.pdf}
\end{frame}

\subsection{Bootchain}

\begin{frame}{Bootchain on ARMv7-A}
  \begin{itemize}
    \item TF-A on ARMv7-A is supported on some SoC but bootchain is often different between them
    \item On SAMA5D2, there is no TF-A support, at91bootstrap is the "SPL" and loads the next software:
    \begin{itemize}
      \item Can be U-Boot, Linux or another binary
    \end{itemize}
    \item At some point in the bootchain, a switch to the normal world happens
    \item Our goal is to minimize the amount of code running as secure
    \begin{itemize}
      \item Only ROMBoot, at91bootstrap and OP-TEE will run in secure mode
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Bootchain on SAMA5D2}
  \center \includegraphics[width=0.8\textwidth]{bootchain_secure.pdf}
\end{frame}

\begin{frame}[fragile]{Booting OP-TEE (1)}
  \begin{itemize}
    \item OP-TEE outputs a binary with a simple header (\code{tee.bin}, V1 header):
   \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{c}
  struct optee_header {
    uint32_t magic;
    uint8_t version;
    uint8_t arch;
    uint16_t flags;
    uint32_t init_size;
    uint32_t init_load_addr_hi;
    uint32_t init_load_addr_lo;
    uint32_t init_mem_usage;
    uint32_t paged_size;
  };
      \end{minted}
    \end{block}
    \item Binary should be copied at \code{init_load_addr} without header
    \item Another multi part header (V2) exists for loader that support separate binaries
  \end{itemize}
\end{frame}

\begin{frame}{Booting OP-TEE (2)}
  \begin{itemize}
    \item Need to pass the following registers when jumping to OP-TEE:
    \begin{itemize}
      \item \textbf{r0}: Page store area pointer (When using \code{CFG_WITH_PAGER})
      \item \textbf{r1}: Normal world first argument
      \item \textbf{r2}: Normal world second argument (External device tree for OP-TEE)
      \item \textbf{lr}: Normal world entry point (Can be hardcoded using \code{CFG_NS_ENTRY_ADDR})
    \end{itemize}
    \item After starting it, OP-TEE is \textit{persistent} in memory an runs in secure world
    \begin{itemize}
      \item Vector table is set for monitor mode (\code{MVBAR}) which allow catching SMC
    \end{itemize}
    \item When returning to normal world (address in \code{lr}), \code{r0} will be set to 0
    \item at91bootstrap has been modified to support OP-TEE load
    \begin{enumerate}
      \item Loads both OP-TEE and U-Boot from non volatile memory into RAM
      \item Set \code{lr} to U-Boot load address
      \item (When booting linux) Set \code{r1} to MACH type and \code{r2} with device tree
      \item Jump to OP-TEE entry point (\code{init_load_addr})
    \end{enumerate}
  \end{itemize}
\end{frame}

\begin{frame}{OP-TEE Device Trees (1)}
  \begin{itemize}
    \item OP-TEE manipulates 2 devices trees:
    \begin{itemize}
      \item Embedded: Secure device tree for OP-TEE internal use (\code{CFG_EMBED_DT} selected by \code{CFG_EMBED_DTB_SOURCE_FILE})
      \item External: Non-Secure device tree meant for Normal World (Passed via \code{r2} or hardcoded using \code{CFG_DT_ADDR})
    \end{itemize}
    \item OP-TEE only works with flattened device tree
    \item External device tree can be modified or generated as a device tree overlay which can be merged by Normal World
    \begin{itemize}
      \item \code{CFG_EXTERNAL_DTB_OVERLAY} will reuse an external device tree overlay or create it if needed
      \item \code{CFG_GENERATE_DTB_OVERLAY} will always create a new device tree overlay
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{OP-TEE Device Trees (2)}
  \begin{itemize}
    \item Device tree property \code{secure-status} allows to set the status of the node for secure world
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
/* Device should be set as accessible by both Secure & Non-Secure */
secure-status = "okay";
status = "okay";
     \end{minted}
    \end{block}

    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
/* Device should be set as accessible by Secure only */
secure-status = "okay";
status = "disabled";
     \end{minted}
    \end{block}
    \item Nodes status in a device tree can be modified using \code{dt_enable_secure_status()}
    \begin{itemize}
      \item Will set \code{status = "disabled"} and \code{secure-status = "okay"} for the node
      \item Useful to change the state of a node after handling it in secure world
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{OP-TEE Device Trees (3)}
  \begin{itemize}
    \item Some nodes can be generated by OP-TEE to pass information to Normal World via external device tree
    \begin{itemize}
      \item \code{optee} node for Linux OP-TEE driver
      \item \code{psci} node for PSCI informations
    \end{itemize}
    \item Other changes to change a system state from Secure to Non-Secure
    \begin{itemize}
      \item SCMI node is not generated and some modifications are needed for SCMI clocks
      \item \code{assigned-clock-parent} handling fails due to missing re-parenting support in SCMI protocol
    \end{itemize}
  \end{itemize}
\end{frame}
\subsection{Securing peripherals}

\begin{frame}{Why securing ?} 
  \begin{itemize}
    \item When running under a TEE, the system must remain secure
    \begin{itemize}
      \item The REE MUST not be able to alter the TEE or system state
    \end{itemize}
    \item Memories containing the TEE data must also remain out of reach of REE
    \item Need to reduce Linux critical peripheral access
    \item Any peripheral that can compromise the system state or the TEE integrity should be secure
    \begin{itemize}
      \item Reset/shutdown, watchdog controllers $\rightarrow$ For obvious reason !
      \item CPU Online/Offline control $\rightarrow$ Obvious reason
      \item Clock controllers $\rightarrow$ Can disable clock of critical devices
      \item Random number generator $\rightarrow$ Could leak random data used for secure purpose
      \item Cryptographic engines $\rightarrow$ Can access secret asset
      \item Bus controllers $\rightarrow$ Can change bus settings (QoS, etc)
      \item Timers $\rightarrow$ Can alter the perception of time for TEE
      \item OTP, Fuses $\rightarrow$ Can access sensitive data (secure assets, key, etc)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Hardware for security} 
  \begin{itemize}
    \item Depending on hardware, bus controllers often provide security settings if ARM TrustZone is supported.
    \begin{itemize}
      \item An additional security bit is conveyed with accesses over the bus
      \item Set peripherals access for secure masters only
      \item Set memories secure layout by splitting them with more or less flexibility
    \end{itemize}
    \item On SAMA5D2, bus controllers (Bus matrix) allow to secure devices and memories:
    \begin{itemize}
      \item Memories can be split according to \textit{regions}
      \item Peripherals state can set as Secure or Non-secure
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{Securing memories}
  \begin{itemize}
    \item TEE memories \textbf{MUST} be set as secure (text, data, etc)
    \item Memories (SRAM/DRAM/etc) can be split in 2 areas for each port according to predefined sizes
    \begin{itemize}
      \item Either the first part is secure and the second part is non-secure or the reverse
    \end{itemize}
    \item When setting a secure memory layout and using DDR, consider all the available boards !
    \begin{itemize}
      \item Some boards have less DDR than others, so try to put OP-TEE in the beginning of the DDR rather than at the end
    \end{itemize}
    \item SAMA5D2 initial memory map for OP-TEE was at 256MiB (\code{0x30000000})
    \begin{itemize}
      \item Memory map modified to put OP-TEE at start of DDR (\code{0x20000000})
    \end{itemize}
  \end{itemize}
\end{frame}


\begin{frame}{Secure DDR on SAMA5D2}
  \center \includegraphics[width=0.7\textwidth]{memories.pdf}
\end{frame}


\begin{frame}{Securing peripherals}
  \begin{itemize}
    \item Security of peripherals is often a combination of peripheral and bus controller settings
    \begin{itemize}
      \item Some registers have different secure behavior for read vs write
    \end{itemize}
    \item SAMA5D2 Matrix buses can set peripheral security world.
    \begin{itemize}
      \item Peripherals are either "Always Secure" or "Peripheral Securable" (can be configured as secure or non-secure)
      \item Peripherals might have additional write protection features for safety
      \item Interrupt are also affected by these settings and will target the secure interrupt controller
      \item Some devices include functions that are used by both world (Special Function Register for instance)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{OP-TEE peripheral security}
  \begin{itemize}
    \item OP-TEE platform code is in charge of setting up hardware security
    \item There is no common framework to handle this, each platform implement it its own way
    \item Can be done using \code{secure-status}/\code{status} property in device tree with \code{_fdt_get_status} which returns a mask:
    \begin{itemize}
      \item \code{DT_STATUS_OK_SEC}: \code{secure-status} is set to \code{"okay"}
      \item \code{DT_STATUS_OK_NSEC}: \code{status} is set to \code{"okay"}
      \item \code{DT_STATUS_DISABLED}: node is completely disabled
    \end{itemize}
    \item Based on this information, peripherals can be set as secure with bus controllers
  \end{itemize}
\end{frame}

% Protocols
\subsection{Communication}

\begin{frame}[fragile]{Doorbell}
  \begin{itemize}
    \item Doorbell mechanism needed to send notifications from REE to TEE
    \item Hardware mailboxes can be used if available
    \item SMC instruction allows to switch from Normal World to Secure World via the Secure Monitor by generating a synchronous exception
    \begin{itemize}
      \item SMC Calling Convention define ranges for function IDs and argument passing
      \item Registers \code{r0} contains the function ID to call and \code{r1 - r7} are used for arguments
      \item Registers \code{r0 - r7} are used to return values
    \end{itemize}
    \item Allows to call specific OP-TEE services handled by \code{sm_platform_handler}
    \item SAMA5D2 does not have mailboxes $\rightarrow$ SMC are used for notifications
  \end{itemize}
\end{frame}

\begin{frame}{Protocols}
  \begin{itemize}
    \item Some protocols allows to control the critical peripherals into Secure World
    \item \textbf{S}ystem \textbf{C}ontrol and \textbf{M}anagement \textbf{I}nterface allows to manage clocks, power and reset domain
    \begin{itemize}
      \item SMCs can be used as the doorbell mechanism for SCMI.
    \end{itemize}
    \item \textbf{P}ower \textbf{S}tate and \textbf{C}oordination \textbf{I}nterface allows to control power states of system and CPUs
    \item OP-TEE driver for specific communication via OP-TEE Message Protocol
    \begin{itemize}
      \item Communication with Trusted Application (TA/Pseudo TA) from Non-Secure client applications
      \item Handles RPC from OP-TEE (Services offered by Non-Secure World, I2C, REE timer for instance)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{SCMI}
  \begin{itemize}
    \item Set of standard interfaces for power, performance and system management
    \item OP-TEE integrates a SCMI server which can handle clocks, power domains \& reset domains.
    \item Linux provides support for SCMI (with \code{CONFIG_ARM_SCMI_PROTOCOL}).
    \item Communication can be done using SMCs or mailboxes
    \begin{itemize}
      \item At the time of this talk, SCMI driver needs \code{CONFIG_ARM_SCMI_PROTOCOL} which needs \code{CONFIG_MAILBOX}
      \item SCMI support via SMC needs \code{CONFIG_HAVE_ARM_SMCCC_DISCOVERY} to be enabled which needs \code{CONFIG_ARM_PSCI_FW} to detect the SMC version supported.
      \item Basic PSCI support is needed in OP-TEE platform to use SCMI driver with SMC.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{SCMI Device tree (1)}
  \begin{itemize}
    \item \code{arm,smc-id} defines the function ID to be used with SMCs to call OP-TEE platform specific SCMI handling
    \begin{itemize}
      \item On OP-TEE side, this function ID must be handled in \code{sm_platform_handler()} to call SCMI channel handling (\code{scmi_smt_fastcall_smc_entry})
    \end{itemize}
    \item A shared memory area (Secure/Non-Secure) must be defined in the device tree for SCMI data exchange
    \item Supported protocols are defined as \code{scmi0} subnodes where \code{reg} describes the protocol identifier
    \item U-Boot also provides support for SCMI clocks and uses the same device tree bindings than Linux
    \begin{itemize}
      \item If clock are needed early in U-Boot, \code{u-boot,dm-pre-reloc} property should be added to SCMI nodes for pre relocation probing
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{SCMI Device tree (2)}
  \begin{block}{}
    \fontsize{9}{9}\selectfont
    \begin{minted}{perl}
      reserved-memory {
        scmi0_shmem: scmi0_shmem@21400000 {
          no-map;
          reg = <0x21400000 0x80>;
        };
      };

      firmware {
        scmi0 {
          compatible = "arm,scmi-smc";
          shmem = <&scmi0_shmem>;
          arm,smc-id = <0x2000200>;

          scmi0_clock: scmi0_clock@14 {
            #clock-cells = <0x01>;
            reg = <0x14>;
          };
        };
      };
   \end{minted}
  \end{block}
\end{frame}

\begin{frame}[fragile]{SCMI Clocks}
  \begin{itemize}
    \item SCMI protocol for clocks allows to query clock count, enable/disable and set/get the rate for clocks
    \item \code{CONFIG_SCMI_CLK} in Linux
    \begin{itemize}
      \item SCMI clocks are probed later that \textbf{clocksources} !
      \item This can be a problem if you have a core \textbf{clocksource} needing an SCMI clock to work
    \end{itemize}
    \item \code{CONFIG_CLK_SCMI} in U-Boot
    \item SCMI identifies clocks using a single integer
    \item Clocks identifier are expected to be contiguous and in the range of \code{[0 - clock_count[}
  \end{itemize}
\end{frame}


\begin{frame}[fragile]{SCMI Clocks}
  \begin{itemize}
    \item Existing device tree should be modified to use SCMI clocks instead of physical ones (This can be a tedious task when using a lot of clocks !)
    \item For instance, this clock description:
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
&tdes {
  clocks = <&pmc PMC_TYPE_PERIPHERAL 11>;
};
      \end{minted}
    \end{block}
    \item Will become:
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
&tdes {
  clocks = <&scmi0_clock AT91_SCMI_CLK_PERIPH_TDES_CLK>;
};
      \end{minted}
    \end{block}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Clocks in OP-TEE}
  \begin{itemize}
    \item Previously no framework to handle a clock tree (custom to each platform)
    \item Pull-Request ongoing to add a basic clock framework
    \begin{itemize}
      \item Adds device tree parsing to query clocks from drivers
      \item Use existing device tree bindings to assign clock parents and rates
    \end{itemize}
    \item SCMI generic clock support will be added and use this generic clock framework
    \begin{itemize}
      \item Proposal is to use device tree bindings to match physical clocks to SCMI clocks
  
      \begin{block}{}
        \fontsize{9}{9}\selectfont
        \begin{minted}{perl}
tdes_clk@19 {
  reg = <AT91_SCMI_CLK_PERIPH_TDES_CLK>; /* SCMI identifier */
  clocks = <&pmc PMC_TYPE_PERIPHERAL 11>; /* Physical clock */
};
        \end{minted}
      \end{block}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{PSCI} 
  \begin{itemize}
    \item Standard interface for power management
    \begin{itemize}
      \item System shutdown and reset
      \item Core idle management
      \item Dynamic addition and removal of cores, and secondary core boot
    \end{itemize}
    \item PSCI support can be enabled in Linux with \code{CONFIG_ARM_PSCI_FW}
    \item In U-Boot, PSCI reset and shutdown are supported with \code{CONFIG_SYSRESET_PSCI}
    \item In OP-TEE platform specific code must be added (weak functions) to handle PSCI request and report supported features
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{PSCI Device tree}
  \begin{itemize}
    \item PSCI node can be generated by OP-TEE in the external device tree
    \begin{itemize}
      \item Allows to always have the correct PSCI SMC function ID
    \end{itemize}
  \end{itemize}
  \begin{block}{}
    \fontsize{9}{9}\selectfont
    \begin{minted}{perl}  
psci {
  sys_reset = <0x84000009>;
  sys_poweroff = <0x84000008>;
  cpu_on = <0x84000003>;
  cpu_off = <0x84000002>;
  cpu_suspend = <0x84000001>;
  method = "smc";
  compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
};
   \end{minted}
  \end{block}
\end{frame}

\begin{frame}{PSCI Suspend, Reset, Shutdown}
  \begin{itemize}
    \item PSCI provides a suspend method to enter system in suspend mode
    \item Semantic for suspend is to enter the deepest suspend mode available
    \item On SAMA5D2, there are multiple suspend modes which are selectable by a command line option (\code{atmel.pm_modes})
    \begin{itemize}
      \item Solution is to use a custom Silicon Provider SMC (SIP SMC) to set suspend mode at boot time
      \item SMC is done according to the existing boot parameter \code{atmel.pm_modes}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{PM Support in OP-TEE}
  \begin{itemize}
    \item OP-TEE provides arch support for suspend support
    \item PM functions allows to register suspend/resume callback that will be called on PM state changes
    \begin{itemize}
      \item \code{register_pm_driver_cb()} and \code{register_pm_core_service_cb()}
    \end{itemize}
    \item platform code should call \code{pm_change_state()} to change PM state
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
pm_change_state(PM_OP_SUSPEND, 0);
      \end{minted}
    \end{block}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{CPU Idle}
  \begin{itemize}
    \item CPU Idle via PSCI is supported in Linux when enabling \code{CONFIG_ARM_PSCI_CPUIDLE}
    \item PSCI idle states must be described in device tree
    \item \code{entry-method} property must be set to \code{"psci"}
    \item Multiple states can be describe and will be chosen according to their usage "cost"
    \item \code{arm,psci-suspend-param} value will be passed with PSCI call to allow TEE to identify the requested idle mode
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Idle states}
  \begin{block}{}
    \fontsize{9}{9}\selectfont
    \begin{minted}{perl}
cpu@0 {
  enable-method = "psci";
  cpu-idle-states = <&psci_standby>;
};

idle-states {
  entry-method = "psci";

  psci_standby: psci-standby {
    compatible = "arm,idle-state";
    idle-state-name = "psci,standby";
    arm,psci-suspend-param = <0x0>;
    entry-latency-us = <1000>;
    exit-latency-us = <700>;
    min-residency-us = <2000>;
  };
};
   \end{minted}
  \end{block}
\end{frame}

\begin{frame}[fragile]{OP-TEE driver}
  \begin{itemize}
    \item An OP-TEE driver is present in Linux
    \item This driver is probed based on device tree and OP-TEE can also generate this node in the external device tree overlay
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{perl}
reserved-memory {
  optee_core@20000000 {
    reg = <0x20000000 0x1000000>;
  };

  optee_shm@21000000 {
    reg = <0x21000000 0x400000>;
  };
};
      
firmware {
  optee {
    compatible = "linaro,optee-tz";
    method = "smc";
  };
};
      \end{minted}
    \end{block}
  \end{itemize}
\end{frame}

\begin{frame}{OP-TEE architecture}
  \begin{figure}[h!]
    \includegraphics[width=0.8\textwidth]{op-tee-software-architecture.jpg}
    \caption{from Linaro}
  \end{figure}
\end{frame}

\subsection{Other Peripherals}

\begin{frame}[fragile]{True Random Number Generator}
  \center\includegraphics[width=0.1\textwidth]{dice.jpg}
  \begin{itemize}
    \item Linux driver for OP-TEE RNG must be enabled using \code{CONFIG_HW_RANDOM_OPTEE}
    \item On OP-TEE side, a Pseudo Trusted Application (\textbf{PTA}) provides access to the secure RNG when \code{CFG_HWRNG_PTA} is enabled
    \begin{itemize}
      \item Linux driver will then communicate with this PTA to query random data
    \end{itemize}
    \item If correctly detected by Linux driver, \code{optee-rng} hwrng will be available and selected as current hwrng:
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{console}
# cat /sys/class/misc/hw_random/rng_available
optee-rng
# cat /sys/class/misc/hw_random/rng_current 
optee-rng
      \end{minted}
    \end{block}
    \item Secure random data are then available using \code{/dev/hwrng}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Timer}
  \begin{itemize}
    \item OP-TEE provide a timer based on \textit{ARM Generic Timer} extension and one using REE time
    \begin{itemize}
      \item A secure timer should be added if SoC does not support \textit{ARM Generic Timer} or to have a more secure timer
    \end{itemize}
    \item OP-TEE provides an interface to register a secure timer
    \begin{block}{}
      \fontsize{9}{9}\selectfont
      \begin{minted}{c}
static const struct time_source atmel_tcb_time_source = {
  .name = "atmel_tcb",
  .protection_level = 1000,
  .get_sys_time = atmel_tcb_get_sys_time,
};

REGISTER_TIME_SOURCE(atmel_tcb_time_source)
      \end{minted}
    \end{block}
    \item Counter should return relative time that has elapsed since a fixed point
    \begin{itemize}
      \item 64bits counter is recommended to avoid wrapping
    \end{itemize}
    \item \code{tee_time_get_sys_time()} can then be used to query the time using this clock
  \end{itemize}
\end{frame}

\begin{frame}{PL310 L2 cache}
  \begin{itemize}
    \item PL310 cache setup is supported by OP-TEE
    \item If configuration is expected to be modified by Linux, \code{.write_sec} function should be set
    \begin{itemize}
      \item Function defined in platform code and should override \code{outer_cache::write_sec()}
      \item Often uses SMCs with custom function ID but no standard for that
      \item Secure/Non-Secure state must be discovered by platform custom code (Device Tree parsing)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Interrupts}
  \begin{itemize}
    \item Currently only GIC is supported by OP-TEE
    \begin{itemize}
      \item SAMA5D2 Support for Secure Advanced Interrupt Controller will be added
    \end{itemize}
    \item Basic interrupt framework allows to enable/disable an interrupt
    \begin{itemize}
      \item Pull-Request ongoing for interrupt specifier (level, priority) support
    \end{itemize}
    \item \code{itr_core_handler()} has to be redefined by platform code to handle irqs
    \item Interrupts used with the bus controller capabilities are \textbf{really} useful to find were the security violations are happening.
    \begin{itemize}
      \item Can display the address of violation and the location where it happened:
      \begin{block}{}
        \fontsize{9}{9}\selectfont
        \begin{minted}{console}
  Matrix 0 permission failure from master 0, address 0x200118b8, mon_lr = 0x3ffa4a5c
        \end{minted}
      \end{block}
     \item \code{mon_lr} points to the address where the violation was generated (read/write)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]{Contribution status}
	\begin{itemize}
    \item OP-TEE:
    \begin{itemize}
      \item Generic clock framework to handle clock tree (In progress: \href{https://github.com/OP-TEE/optee_os/pull/4705#}{4705\#})
      \item SCMI clock support based on device tree (TODO)
      \item SAMA5D2 enhanced secure support (Clocks, SCMI, suspend, reset, shutdown, interrupts, TRNG, Timers) (TODO)
    \end{itemize}
    \item at91bootstrap:
    \begin{itemize}
      \item Support for OP-TEE loading (In progress: \href{https://github.com/linux4sam/at91bootstrap/pull/128#}{128\#})
    \end{itemize}
    \item Linux:
    \begin{itemize}
      \item SAMA5D2 PL310 L2 cache \code{write_sec()} support (TODO)
      \item SAMA5D2 Secure suspend support (SMC to select ) (TODO)
    \end{itemize}
  \end{itemize}
\end{frame}

\questionslide

\begin{frame}{Going further and sources}
	\begin{itemize}
		\item OP-TEE Documentation : \url{https://optee.readthedocs.io/en/latest/}
		\item SCMI specification: \url{https://developer.arm.com/architectures/system-architectures/software-standards/scmi}
		\item PSCI specification: \url{https://developer.arm.com/architectures/system-architectures/software-standards/psci}
	\end{itemize}
\end{frame}

\end{document}
