OP-TEE Using TrustZone to Protect Our Own Secrets

As his talk was in a much too small room on day one, my colleague Marc Kleine-Budde got a 2nd chance to talk about OP-TEE and storing data in the trustzone in a secure way. The room was well filled with visitors, so giving the talk a 2nd time seems to have been the right choice.

The "Trusted Execution Environment" (TEE) is a small isolated environment for sensitive code and data. The idea is that only a small ammount of code runs in the TEE, leaving the major part of the functionality for the normal Linux environment. On ARM, TEE can be implemented with the help of the "trustzone" technology: while the code runs on the same CPU, the processor hardware isolates the code in a separate mode which has more permissions than normal operating system code ("secure world"). The only way to switch between normal world and secure world is a call into the secure monitor.

In secure world, the hardware makes sure that access to certain parts of the address space is limited. It is also possible to restrict access to certain hardware units (but this mode of operation has its own issues). On ARMv7, the secure monitor is implemented in OP-TEE, while on ARMv8 it is part of the "trusted firmware". After bootup, the system initially starts in secure state.

OP-TEE was initially implemented as proprietary code; in 2015, it was relicensed and published under the BSD license. Since 4.12, the kernel part (implementing the Global Platform API) is in Linux mainline. Currently, there are about 20 ports in the kernel. The OP-TEE mini operating system consists of the TEE core, an internal API and the trusted apps.

On i.MX6, the boot process is secured via HABv4; OP-TEE is integrated into the bootloader (barebox in our case) and is executed during startup. Barebox checks the signature of the kernel (FIT image) and starts the rest of the system. The OP-TEE code continues to exist during the lifetime of the system and is called in case of a secure monitor call. As our experiments were gained as part of this year's Pengutronix TechWeek, we just got the base mechanisms working. For the future, some features for real applications would be helpful, such as adapting OP-Tee to the kernel's keystore API. With such a mechanism in place, the trustzone could be used to securely store keys.

During the discussion, several security issues have been addressed; surprisingly, it turned out that security is complex and there are no guarantees that mechanisms cannot be circumvented. However, the audience and the involved people would like to see more people being involved, in order to get more testing, fuzzing etc.

Stable Device Tree ABI - It's Possible

After the lunch break, my colleague Lucas Stach reported about strategies to ensure ABI stability of open firmware devicetree bindings. One motivation for ABI stability is that the embedded systems we do at Pengutronix are usually based on the mainline kernel; production systems will be provided with new kernels for quite some time.

While the kernel initializes from oftree for quite a while now, other components start making use of it as well (barebox, U-Boot, secure world firmware). Some devicetree properties are well established (i.e. memory nodes), but for many peripherals it's not immediately obvious how to model them in oftree, so bindings will change over time. So assuming absolute devicetree longterm stability is no valid strategy.

The expertise outlined in the talk was gained while maintaining the i.MX platform and represents what maintainers learned during the last years. The first step when defining a stable binding is to look into the datasheet of a component: all hardware properties need to be described in the binding - not only that ones which are being used in the currently relevant design. It is important that mandatory compatibles are stable from day one: later on, it's not possible to change them any more without additional maintenance burden. For new variants of existing IP blocks new compatibles should be defined: for instance, the SPI core on MX6 ULL got the compatible "fsl,imx6ul-ecspi, fsl,imx51-ecspi". The driver only makes use of the last part for now, but in case hardware differences are found, the first information is already available. In case modifications need to be made, they should be done in the kernel, not in oftree.

In result, Lucas explained that the set of rules to be followed for a stable devicetree ABI is small. The talk was followed by an engaged discussion which showed that the topic is more complex than many people expect.

swupdate

Stefano Babic reported in my next talk about the swupdate project; for me, it was interesting to see how other developers address issues in the same area where we use RAUC at Pengutronix.

The talk started with an introduction about update usecase, based on USB sticks up to network based setups. swupdate can (similar to RAUC) make use of the hawkBit update server. It is also possible to implement a secure fallback to an existing update slot. Other requirements such as atomicity or making sure that only properly validated firmwares are rolled out to the field are more or less similar to what we are used to.

swupdate exists since 2014 and is licensed under GPLv2/LGPLv2. During the last time, it found quite some contributors. The system has a local interface, it is possible to integrate it into applications and it provides a set of OTA update variants. Yocto and buildroot integration is availabe; the supported bootloaders are U-Boot and grub. swupdate's update format is based on CPIO. There are handlers for different backend store device and a LUA scripting facility. Boot counters are possible when being used with U-Boot. The developers have topics like bootloader fallback, file updaters, a progress indication interface and a streaming update mechanism on their agenda.

Zero-Copy Video Streaming on Embedded Systems the Easy Way

In the last Pengutronix talk of the conference, Michael Tretter and Philipp Zabel talked about their experiences how to reduce memory bandwith in video streaming scenarios. The usecase are systems that capture video with a sensor, process it, transfer it via some network channel, receive it on a 2nd system and display it. The tasks need a certain amount of processing power, while the systems often have low power requirements.

One of the typical issues is that the various components in the SoCs need their data in special colour formats: cameras provide bayer pattern, encoders/decoders need YUV, while 3D units understand tiled formats. The task is to move those video buffers around without wasting memory bandwidth.

The 3D units, used i.e. for geometrical transformations such as lense correction, are covered by the Etnaviv project; the relevant patches are now in MESA and Linux mainline. The output side is covered by the imx-drm driver, while the video encoder/decoder handling is done by the coda driver, which is also part of the mainline kernel.

The main feature to hand over buffers between several control blocks is the dmabuf mechanis: it makes it possible to transfer control over a kernel allocated buffer between several userspace components by handing over a filedescriptor handle; userspace doesn't have direct access to the memory addresses any more, and the kernel is responsible for buffer allocation and life time management.

After showing some v4l2 and EGL examples (which indeed did not look easy), Michael and Philipp showed how to make use of all those features from within GStreamer. The internals of the examples are still not easy, but at least from the user perspective it looks easy... More complex scenarios with compositing of video and GUIs are usually realized with Wayland these days.

The camera input side of the game stays complex for now: the pipelines need to be configured with media-ctl. The developers are currently working on providing better default settings to configure cameras in a way that they at least output some video without further config steps. In addition, atomic mode setting is being implemented for wayland by others in the community, but those patches havn't landed in mainline yet.

Closing Game & Attendee Party