U-Boot became the de facto bootloader on most ARM systems during the early 2000s. It grew out of an earlier flora of smaller and custom boot loaders such as RedBoot and Open Handhelds ARM Bootloader. Currently the main alternatives are the Little Kernel bootloader, which has been used by Qualcomm and Google for a series of Android devices, and the UEFI-compliant Tianocore (also known as EDK II) bootloader.

What is the best bootloader to use for any one system is a subject of debate. There have been pushes to different “there can be only one” approaches, but the recent consensus is to “use the right tool for the job”, while people may have differing opinions on what the right tool is.

Boot Chain
All SoCs have some way to bootstrap their CPU(s) to execute code on cold start. On an older ARM32 system, the execution is usually started in an on-chip ROM, which in turn continue execution either in NOR flash (memory-mapped flash memory) or by initializing the main RAM (which is normally not accessible at boot) and loading a proper boot loader from a NAND flash or eMMC or SD card.

Sometimes several steps need to be performed to boot a system, and as some code may need to execute from on-chip memory or locked down cache until the RAM is initialized, initial steps can be very small boot stages (programs).

Eventually a fairly large program single-threaded program is loaded into memory, and its task is to load and execute the final operating system from images (binary objects, files) stored on some media. For simplicity, this program is usually executed from 1-to-1-mapped physical memory. This program may also have the ability to reformat and install new images on the system.

This program is referred to as the boot loader. The stages up until this program is loaded is handled by ARM Trusted Firmware on the ARM reference designs for AArch64.

The boot loader will typically be a bit interactive (has a prompt) and support booting the final operating system from hard disk, memory card, flash memory, ethernet connection, USB cable, or even through light morse code from an IrDA sensor. It places the final operating system image in memory, passes some information to it and kicks off execution at the start of executable memory.

From this point, the operating system needs to set up virtual memory, caches and everything else needed to get the system into full-flight mode.

Chain of Trust
If a chain of trust shall be preserved across these stages, the first point of execution needs to be trusted and contain routines for checking validity of the next executable program all the way. This is usually achieved using public key cryptography, where a public key is stored in the ROM (or similar location inside the device) and binaries to be executed need to be signed by the secret key corresponding to that public key. This way the device will not contain any secret keys. Sometimes a certificate chain is used to distribute the signing authorization.

Initial U-Boot AArch64 Support
The AArch64 (ARM64) support for U-Boot was pioneered by Scott Wood, David Feng and York Sun from Freescale in 2013 to support their LS2085 platforms. Leo Yan from Marvell joined the efforts, and thanks to these people U-Boot can start and boot Linux on a range of ARMv8/AArch64 systems.

ARM Fastmodel Support
Freescale’s submissions included fastmodel support, a specific customization known as Foundation model or simply FVP. This is a cycle-exact AArch64 emulator made by ARM Ltd, which behaves akin to a Versatile Express reference board, just with the difference that the whole system is emulated in software.

In order to load binary images into the emulated memory, so-called semihosting is used. This is basically a way for the code running on the emulator to talk directly to the emulator, i.e. for it to be aware that it is not running on real hardware. By issuing a parametrized HLT instruction, the code running in the model can ask for services, such as to retrieve files into the memory, from the emulator.

When I started working on AArch64 support for U-Boot I augmented this code a bit so that we now have a command called smhload that will load a file into the emulated memory akin to how files are loaded from flash memory or over Ethernet+TFTP.

By working on the Foundation model, I could verify that execution and interactive prompt was working, and I could continue with support for real reference hardware.

ARM Juno Development System Support
Freescale’s attempt had been focused around emulated reference hardware and later their own hardware. When I started working on AArch64 the scope was on the 64 Bit Juno ARM Development Platform. The idea was to showcase U-Boot on this real hardware as a reference point for the rest of the ARM vendor ecosystem. If we could get U-Boot working nicely on Juno, we could provide a trusted starting point for others.

First we had to make Juno start the compiled U-Boot. ARM recommend that U-Boot is started from the ARM Trusted Firmware, which is essentially the ROM for the Juno. The trusted firmware performs the boot chain as described above in several stages or Boot Levels called BL1, BL2, BL3-1, BL3-2 BL3-3. I only needed to consider myself with the last boot level, BL3-3, which is the level containing a “real” bootloader binary. In the examples, BL3-3 was Tianocore UEFI. By compiling U-Boot to address 0xe0000000 and replacing UEFI with the resulting binary, U-Boot was executed by the ARM Trusted Firmware.

At first the system would not boot at all – the Juno went catatonic. By instrumenting U-Boot with a low-level UART print hack to push strings to the console before initializing the rest of U-Boot, I could determine the cause: the MPIDR (Multi-Processor ID register) had totally different meaning and contents on a multi-cluster machine. The U-Boot code was adapted for a single cluster of symmetric CPUs, not for multiple clusters of CPUs, such as the cluster of two Cortex-A57s and four Cortex-A53s found on the Juno.

Freescale’s system had the ROM or similar mechanism enter U-Boot from both CPUs, and when it reached U-Boot all slave CPUs were immediately dispatched to a spin table while execution of the single-threaded U-Boot should continue on the primary CPU. However the branch_if_slave assembler macro would think all CPUs on the system were secondary CPUs.

Since the Juno board was only initiating execution of the boot loader on the primary CPU, this problem was solved with a patch making U-Boot assume single entrance (i.e. only one CPU will execute it) and after this we got all the way to prompt. A special configuration symbol, ARMV8_MULTIENTRY was created for systems such as Freescale to select. This way single-entrance was made the norm.

Now U-Boot was working to prompt at Juno hardware, so I could test loading a kernel by compiling in Y-modem binary loading support and uploading a kernel Image file and a device tree to the memory and start execution using Y-modem and boot it. It worked fine. A patch for initial Juno support was submitted upstream and merged.

Uploading a big kernel and initramfs over the serial port at 115200 baud was quite tiresome, so I immediately started to get U-Boot to load kernels over the ethernet port, resulting in a patch supporting SMSC9118 ethernet booting. This was it is possible to quickly boot a kernel using ethernet and TFTP.

It was now quick and efficient to develop Linux using U-boot, especially if you compile in a boot script into the ethernet/TFTP boot so that all you really need to do it reset the machine and it would immediate download a new kernel from the TFTP server and run it.

However it is nice to be able to flash a kernel and a filesystem into the on-board flash memory in the Juno and use that to just boot the machine, especially for demos and similar where you want to prepare the machine and just use it. Thus I also added flash support to the Juno, the tricky part being a patch to handle the AFS partitions in the flash – this was a new ARM-specific flash image format that relies in footers in the end of the last erase block of the flash. After adding this, I could make a patch making this the default boot method for the Juno, so the boot chain was self-contained on the device.

Future Directions
We now have pieced together a system that will start U-Boot from ARM Trusted Firmware and then have U-Boot load the Linux kernel and a device tree and start it. Are there problems remaining?

• One of the big outstanding issues are those where things are fragile because memory references need be hard-coded in U-Boot or ARM Trusted Firmware. For example U-Boot currently assumes that ARM TF will use 16MB of the DRAM memory. If the ARM TF change things around and use more or less memory, U-Boot needs to be reconfigured and recompiled. U-Boot on the other hand, will then pass whatever knowledge it has about the memory to the Linux kernel by augmenting the device tree. So if ARM TF could communicate the memory available to U-Boot and the OS this would be great.
• U-Boot relies on prior boot stages such as ARM Trusted Firmware to install PSCI handlers, while on ARMv7 this was usually done by augmenting U-Boot to do the same. Letting U-Boot install PSCI handlers is a bit bogus, since it is a piece of resident code left in memory after U-Boot has executed and not really “boot loader” code. U-Boot was augmented to compile these into a special memory area, copy them there and leave them around for the operating system to use later. Still there are people who might like to do this on ARMv8 U-Boot, especially those not using ARM Trusted Firmware.
• People apparently toy with the idea of booting U-Boot on bare metal, using a very small or no ROM nor ARM Trusted Firmware, letting U-Boot just execute immediately on the system. As U-Boot relies on something else to set up main memory and providing PSCI, this currently does not work. Doing this would require U-Boot to initialize memory and install PSCI handlers. It would also need to be small enough to execute from on-chip RAM.
• Chain of trust booting with signed boot levels, signed U-Boot and a signed kernel image and a signed device tree, making an example of a totally locked-down system. The Flattened Image Tree (FIT) supported by U-Boot is likely the best way forward here, but requires U-Boot to access public key infrastructure to verify images unless you want to compile the public key directly into U-Boot, which is often not a good idea.
• Fastboot – the Android boot protocol used by the Little Kernel, exists in U-Boot but has not been tested or verified. It can use USB or Ethernet alike.
• More hardware support – such as booting from the USB stick or MMC/SD card found in the Juno board. This was not covered by the experimental port.

The Linaro Digital Home Group (LHG) will once again be very active at Linaro Connect San Francisco 2015 (SFO15) and has scheduled a wide array of interesting events, presentations, and demos.

Linaro Connect is a great time for all the LHG engineers to get together to showcase to the open source community what we’ve been up to over the last six months.  On Tuesday September 22nd there will be several sessions dedicated to Digital Home topics as well as demos later in the week that are aligned with the overall ‘Security’ theme of SFO15.

LHG will have the following presentations on Tuesday:

Title: SFO15-201: Boot Architecture for RDK

Abstract: A uniform boot sequence allows RDK systems to have predictable start-up behavior. RDK would like to use a two-level boot architecture, where the primary bootloader is device specific and initializes system registers, memory controller, and hardware resources, and the secondary bootloader implements more complex boot requirements like code download, system disaster recovery and firmware validation.

Title: SFO15-205: OP-TEE Content Decryption with Microsoft PlayReady on ARM TrustZone

Abstract: This presentation gives an overview of how various components of set-top software are integrated to provide a W3C EME solution employing a commercial DRM integrated with an open source TEE running on ARM TrustZone.

Title: SFO15-209: Cisco Connected Life IoT Gateway

Abstract: Experiences productizing the gateway (from hobby to product) and the challenges for IoT deployment scenarios: Home security, Home automation, Home healthcare, and Enterprise IoT (smart manufacturing).

In keeping with the security theme for the week, LHG will have a special event dedicated to “Security in the set­top box” on Wednesday Sept. 23rd. The event is entitled: Expanding security choices: DRM and CA Interoperability.  The event will feature the CTO of Verimatrix, Petr Peterka, who will give a presentation discussing Enhancing Operability for Robust Revenue Security. This presentation will be followed by a panel discussion with industry leaders discussing the challenges and opportunities in the evolving set­top security space.

Finally at the traditional Linaro Connect Demo­ Friday, LHG will be highlighting the following demos:

• ­Microsoft PlayReady Integrated with OPTEE
• ­Linaro Clear Key solution on HiKey Board
• ­Qt Apps with Wayland for the RDK

Those attending Linaro Connect are welcome to come to any and all of the LHG sessions and events.  If you are not able to attend you can visit the Linaro Connect SFO15 page to view recorded sessions and get access to select materials.  Hope to see you there.

Linaro Connect SFO15 is just around the corner and we are expecting another great event.  There will be daily keynotes given by several industry leaders, numerous interesting sessions that attendees will want to participate in, afternoon hacking and a lot of meetings.  So how do you keep track of everything happening each day?  You will need to logon to the very easy to use Pathable event schedule system.  

Pathable allows attendees to see the daily schedule of all activities, select just the ones they would like to attend, schedule meetings, have discussions with other attendees and receive important notices of any changes or additions to the schedule.  It is also where all the content for each session will be posted first, so any links to presentations or videos will be posted under each session as soon as they are available.  

This site will be the place to help you get the most out of your time at Linaro Connect SFO15 so it is really important that you:

1. Go to the site and login prior to the event
2. Set-up your profile and become familiar with the site and how it works
3. There will be a “mobile app” available for you to install from the app store to access the community.  This will be coming shortly.  We will let attendees know as soon as this is available.

Below are some steps to help get you started:

Step 1:  Go to the pathable site:  https://sfo15.pathable.com/

Step 2:  Login – If you have registered for Linaro Connect SFO15 you should have received an email from pathable after 10 Aug with your login details. This email was entitled: “Please join Linaro Connect San Francisco 2015″. If you cannot find this email please send an email to: connect@linaro.org

Step 3:  Once you get logged in – You will want to update your profile page so that other attendees know who you are, as well as set-up your password to something you can remember easily.  

Step 4:  Add Tags to your profile to identify teams you work with or areas you are interested in.  You can see a list of the current tags being used by going to:  Attendees>Tags (in the left hand drop down), but you can add your own as well.  When people perform a “search” in the attendees or members list, they will be able to choose from the networking interests and tags you and the rest of the community have added to their profiles.

Step 5:  Review the current schedule https://sfo15.pathable.com/meetings  and add sessions you would like to attend to your schedule https://sfo15.pathable.com/meetings/my.  

• Click the Schedule tab
• Hover your mouse over the session description box that pops up that you would like to select and click the “Add” button that appears.
• If you are on a tablet computer or wish to read more before making your choice, select the name of the session you are interested in. Then click the “Add to My Agenda” button to add the session to your schedule.
• You can then go to the My Schedule page to see your agenda for each day

Step 6:  If you need to have any meetings with other attendees you can also easily set those up through Pathable.  

• Visit the profile page of the person you would like to meet
• Click the Schedule a Meeting option
• If you would like to add additional people to the meeting, type their names into the “Attendees” field
• You will see the schedule and free-busy time for you and the invitees on the right. Use your mouse to select a time that is mutually available.
• Select or enter a Location for your meeting*
• Type “Subject” and “Description” for the meeting to give the invitees background on why you would like to meet
• Click the Send Invitation button.

​Your recipients will receive an email notification for the meeting with the option to accept or decline your request. You will receive an email notification when they have responded.

*Most meeting rooms are books however, there are many areas around the hotel to meet.  There is the option to have your attendees meet at the registration desk or put in your own location.  If you need a specific room please see the registration desk.

For more help with Pathable:
These are the basics for Pathable however, there is much more you can do with the tool; including messaging other attendees, having a group chat, adding documents for a sessions etc.  To get more details you can visit the Pathable Knowledge Base to learn more.  http://support.pathable.com/knowledgebase

“Tell everyone what you want to do and someone will want to help you do it.” ~ W. Clement Stone

“Tell everyone what you want to do and someone will want to help you do it.” ~ W. Clement Stone

“Once a word has been allowed to escape, it cannot be recalled.” ~ Horace, Epistles

“Experience is directly proportional to the amount of equipment ruined.” ~ Harrisberger’s Fourth Law of the Lab

“Of course, some people consider hidden bugs to _be_ fixed. I don’t believe in that particular philosophy myself.” ~ Linus Torvalds

LHG takes another step forward in Enhanced Content Protection with OPTEE on ARM® TrustZone®

Mark Gregotski and Zoltan Kuscsik

As studios begin creating ultra-high definition (UHD) content and delivering it to customer devices, a higher level of content protection is required. As a consequence of these more stringent requirements, the digital rights management (DRM) solutions that protect the content, as well as the keys used to decrypt the content, are moving from software to hardware based solutions. Hardware-based security systems allow the security and robustness rules for premium content to be satisfied.

A secure Trusted Execution Environment (TEE) allows the security processes related to key management, content decryption, and content decoding to be executed in a secure environment, not accessible from user space. An example implementation of a TEE, is the Linaro OPTEE that runs on ARM-based CPU TrustZone® architecture.

In addition, commercial DRM porting kits are now available that interface to a TEE to take advantage of this secure hardware functionality. An example, is the latest Microsoft PlayReady® DRM porting kit designed to interface to a generic TEE. The PlayReady interface for Trusted Execution Environments (PRiTEE) is implemented in the PlayReady PK 3.0 release.

PlayReady Device Based Content Protection Improvements [1]

In September of 2015, the Linaro Digital Home Group (LHG) provided the first integration of PlayReady PK3.0 with OPTEE [2]. In that implementation, the PlayReady PK interfaced with OPTEE and the content decryption was performed by a Trusted Application (TA) running in OPTEE using the OPTEE decryption functions.

In the recent implementation, LHG has completed the entire integration of the PlayReady DRM libraries with OPTEE. LHG created a GlobalPlatform compliant TA running on OPTEE that can fully encapsulate the PlayReady DRM as a static library.

The GlobalPlatform (GP) based trusted applications have multiple parts:
API for the normal (non-secure) world. This is the GP TEE Client API (v1.0).
API for the secure world. This is the GP TEE Internal Core API (v1.1). See [3] for both API specifications.

For the non-secure world we pass the PlayReady data using GP to the TA, and we are using various GP secure functions to implement the OEM specific specific requirements for the PlayReady TA (such as, memory allocation using GP memory allocation functionality).

In this solution, the license parsing, key management and the content decryption is performed inside the secure context. This architecture ensures that the TA is aligned with the PlayReady architecture requirements for hardware level DRM protection.

The Open CDMI [4] is an open interface that enables the integration of the DRM/CDM into a browser or media application. The OpenCDM module communicates with the TA using the Microsoft PRiTEE interface and exposes the Open CDMI interface for decrypting PlayReady protected content using the Encrypted Media Extensions in Chromium.

High level overview of Media and Security Components

There is a demo running on the STMicroelectronics B2120 reference platform and we are in the process of porting this build to the HiKey 96Boards platform.

The latest solution is accessible now to our members who are PlayReady Licensees; so we look forward to see it running on multiple ARM-based hardware platforms in the upcoming months on both Android and Linux.

The next stage that LHG is working on is the implementation of a secure video path that uses a secure buffer memory allocation framework in TrustZone for the media pipeline. Stay tuned for the latest updates in the LHG security solution development.

1. https://www.microsoft.com/playready/features/EnhancedContentProtection.aspx
2. http://www.linaro.org/news/linaro-and-microsoft-collaborate-on-secure-media-solutions-for-arm-based-socs/
3. http://globalplatform.org/specificationsdevice.asp
4. https://github.com/kuscsik/linaro-cdmi

“Digital circuits are made from analog parts.” ~ Don Vonada

• Background
• Linaro gets into the picture
• Software components
• Host application
• Test Trusted Applications
• What about the tests coming from GlobalPlatform?
• Licenses
• Shortcomings and future improvements
• Final words

Why you need to test your software is quite obvious and therefore this blog post will not be about that, instead I’ll talk a little bit about how we are testing OP-TEE using a tool called xtest (optee_test). I will also talk about what components are involved, what kind of tests are performed, what is missing, etc. But first let’s start with a short background.

Background

Just as the other components in OP-TEE the test framework also has origins from ST-Ericsson and STMicroelectronics. A couple of years ago, when OP-TEE was being developed, the developers were engaged in GlobalPlatform testing, in the so called TestFest (for simplicity let’s call it OP-TEE even though it strictly isn’t correct, since back then the TEE solution didn’t really have a name, it was the ST-Ericsson TEE solution). At this time there were no official test suite nor compliance program ready and the goals with the TestFests were twofold, first to ensure that the different TEE vendors respective TEE solution was behaving according to the specification, secondly that the test tool(s) and the specifications themselves were correct. At the same time as this work took place there were quite a few “standalone” test cases being implemented as a complement to the GlobalPlatform tests. The nature of those were more to address the missing pieces in GlobalPlatform and to test corner cases, hardware- and extended features. So side by side the engineers at ST-Ericsson were running their own tests as well as the tests provided by the ones in charge of GlobalPlatform compliance program.

Figure 1: Output from xtest

Linaro gets into the picture

When Linaro got involved in the development of OP-TEE we also had a need for testing the code we are developing and at the same time we would like to give our members the ability to use a suitable test framework. The only problem was that the test cases coming from GlobalPlatform couldn’t be shared with anyone (including Linaro) since to get access to those, a company either had to be a member of GlobalPlatform or it had to purchase the needed files directly from GlobalPlatform. Therefore the engineers from ST immediately started working on separating  the tests implemented by themselves from the ones that they had gotten from GlobalPlatform. When that job was completed, they shared their own developed tests with Linaro engineers and the members of Linaro. This piece of test code is what we today refer to when saying “the standard test” and that is also what you can find on GitHub since a couple of months ago on the OP-TEE project in the git called optee_test. That repository is no longer private to Linaro and its members.

For OP-TEE development we have configured our repositories at GitHub so that a pull request will trigger a Travis job which in turn would automatically trigger builds for all supported platforms. In addition to that we always will automatically run xtest using QEMU (here is an example of how that could look like). In the long run we would like to also start using our own Linaro infrastructure (Jenkins + LAVA) as a complement to Travis so that we could do automatic testing on all the devices we are supporting in OP-TEE.

Software components

The test framework consists of a host application, which is a normal user space application running in Linux. This is the piece of software that initiates and runs the actual tests and gathers test results etc. When it comes to Linux kernel there are no changes at all. It’s still the same TEE driver in use that is responsible for transporting the data back and forth between normal world, user space and secure world. Likewise on the secure side, there are no changes to the secure OS itself (TEE core). Instead all the code specific totesting will be performed as a set of different Trusted Applications (I’ll go more into details further down in this blog post).

Host application

The host application, which by the way is the one we call “xtest”, has been divided into a couple of different files where each file corresponds to a certain area or feature. As of writing this, you will find the following files for the host application (there are a few more files, but those other files are the application and test framework itself):

• xtest_1000.c: contains the OS related tests – basic OS features, panics, wait functionality, RPC messaging, signature header verification tests by loading a fake and a corrupt Trusted Application. It also tests invalid memory access and concurrent usage of Trusted Applications.
• xtest_4000.c: contains all crypto related testing. It is basically testing crypto APIs that are exposed to the Trusted Application via the GlobalPlatform Internal TEE core specification.
• xtest_5000.c: this file have tests for shared memory handling.
• xtest_6000.c: contains test for storage, which exercises the GlobalPlatform secure storage API as well as the underlying “POSIX” file system API.
• xtest_7000.c: This also contains tests for shared memory etc. However, this is something that will only be used when having access to and enabling the tests coming from GlobalPlatform (more on that further down in this blog post).
• xtest_10000.c has test code containing extensions going beyond the GlobalPlatform specifications. For example, this is where we are testing key derivation functionality like PBKDF2, HKDF and Concat KDF.
• xtest_20000.c this file also has tests related to storage, but this time those are more aimed at the secure storage implementation as such and they verify that files are actually being written to the file system, checking that they haven’t been corrupted and that they are being deleted etc. As an example, when initiating a store operation from secure world there should be file(s) created in Linux and accessible at /data/tee/{directory}/{filename}/block.xxx.
• xtest_benchmark_1000.c: This is so far the only file related to benchmarking and it contains a couple of benchmark tests for the secure storage implementation.

The main function could be found in the file xtest_main.c. This file basically just lists all test cases that should be enabled, and parses a few command line arguments followed by starting the actual tests. If you dive into the test code itself, you will see that the test framework itself implements macros that are used to evaluate if the test has passed or failed. You will, for example, frequently see ADBG_EXPECT_TEEC_SUCCESS, ADBG_EXPECT, ADBG_EXPECT_TEEC_ERROR_ORIGIN, ADBG_EXPECT_TRUE and ADBG_EXPECT_TEEC_RESULT everywhere in the test code. There are others, but those are the most commonly used.

On a top level, a test case is added using the macro ADBG_CASE_DEFINE and that is what you can see on the top in each and every file listed above. As arguments, this macro takes a test label, a function pointer, a title, a short description of what it is testing, requirement ID and a short description of how it will be tested. As an example, have a look at XTEST_TEE_10001 which is defined here. As you can see, this particular test is supposed to test functionality related to key derivation.

Within each test you can define sub-tests and to do so you have to wrap your code in-between Do_ADBG_BeginSubCase() and Do_ADBG_EndSubCase() calls. This isn’t something you strictly need to do, but it is a nice way of splitting up the tests into manageable sections, that will help better pinpointing where something went wrong in case of a test case failure. The number of tests and subtests is also something that will be presented when all test cases have been run (see Figure 3 further down).

Test Trusted Applications

As I’ve mentioned above, all code related to testing could be found within a set of Trusted Applications. Below is a list of the Trusted Applications that are used by xtest.

• concurrent: The concurrent Trusted Application is responsible for testing the ability to run several Trusted Applications simultaneously – a feature that has been merged into OP-TEE quite recently. For the host application you will find this application’s code in the xtest_1000.c file.
• create_fail_test: This is a tiny little TA used solely to test OP-TEE’s behaviour when loading a corrupt or fake Trusted Application.
• crypt: Despite the fact that there is the crypto API defined by GlobalPlatform, in OP-TEE, this particular Trusted Application also contains an AES-ECB and a SHA-256 (224) implementation within the TA itself, that is mostly due to historic reasons. But the majority of the entry points are calling GlobalPlatform Internal API functions. This Trusted Application tests MAC, AAED, hashes, ciphers, random number generator etc.
• os_test: Mainly tests OS related features such as memory access rights, properties, time API and floating point operations as well as the MPA library (implementing big numbers).
• rpc_test: Test that the RPC mechanism and loading of other Trusted Applications are working properly. It does this by letting the TA itself calling functionality in the crypt TA which will trigger loading of the crypt TA using RPC messages.
• sims: Testing the Single Instance and Multiple Session features specified by GlobalPlatform.
• storage: Contains tests related to the (secure) storage functionality. It tests all the functions of the GlobalPlatform specification that cover the so called “Persistent Objects”. On a high level or in Unix terms, this can be seen as the POSIX API (in reality there is a POSIX level behind the GP interfaces).
• storage_benchmark: As the name indicates, this TA benchmarks storage operations. It reads and writes data of various chunk sizes and then in the end creates a performance report.

What about the tests coming from GlobalPlatform?

The compliance test suite (GlobalPlatform TEE Initial Configuration Compliance Test Suite v1.1.0.4) that can be purchased from GlobalPlatform (free for GP members) consists of a compliance adaptation layer specification that needs to be implemented to run the tests. It also contains a set of configuration files, more specifically – XML files specifying how functions should be called, what parameters to pass to them and what kind of test results to expect, i.e., you will not get any actual code that is ready to be compiled. How those XML files will end up being used is up to the end user. What we did early on was to configure xtest, so that it would be easy to extend it later to also include the compliance test suite from GlobalPlatform. So by putting the XML files on a certain path, using the adaptation layer, installing a couple of tools (xalan) and running make with the “patch” as an argument, there will be a set of new Trusted Applications as well as patch xtest itself to also include the compliance tests. I.e., the XML files will be transformed into C code in this step. After performing that step you will not only run the so called standard test, but you will also run the compliance tests from GP in the same run.

Figure 2: xtest overview

Licenses

One has to be careful when working with xtest, since there are different licenses in use in different areas. In general we usually use BSD Clause-2 license for most of our code. But in this case, when it comes to test related code, we’re using both BSD Clause-2 and GPLv2 license. All code running on secure side in the standard tests (Trusted Applications) are using the BSD Clause-2 license while the code running in normal world is using GPLv2 license. The same is true for the code used when extending xtest, however we must also follow the license stated by GlobalPlatform (GlobalPlatform Compliance License Agreement). In figure 2 below, you can see more clearly how xtest is divided and what licenses are in use.

Shortcomings and future improvements

Today xtest is a test framework that does API testing of the exposed functionality for the Client API and for the Internal Core API. It contains quite a few test cases. Running the standard test on QEMU (Intel Core i5-4670K CPU @ 3.40GHz) results in the following:

Figure 3: xtest standard test result

If you also enable the GP compliance tests, then you get even better coverage. So the APIs as such are being thoroughly tested and that is all good. However! Since it is security we’re dealing with here, we still have a lot to do when it comes to performing a focused security testing. There exist both concepts and tools and even companies solely dedicated to white box testing, where the goal is to find bugs and potential vulnerabilities in the code. For example, over the years people have found numerous bugs in Linux kernel by using Trinity (fuzz tester). With Trinity the main goal isn’t strictly about enhancing security but rather to ensure that the system calls in Linux kernel are robust. A crash (Linux kernel oops) can in some cases also be an entrance point for a kernel exploit and therefore it is still important to find and fix issues discovered by such tools as Trinity. Having something similar running on the secure side would probably be really useful. We have heard that GlobalPlatform will include fuzz testing in a new test suite that is currently being developed (draft is available for GP members here TEE Security Test Suite v0.1.0).

There are also side channel attacks. Some side channel attacks, like power analysis, cannot be done in software only, but still it would be worth adding tests covering such cases when possible. For example, timing attacks are something one can do using only software and having test cases automatically performing timing attacks would be very useful. Since we mainly use ARM TrustZone™ it would also be worth adding tests covering the boundaries between the two worlds. I.e add tests that ensure that memory is or isn’t accessible from the other side. There are some memory region tests in xtest already today, but it would be great to  add more tests in this area. With some imagination one could also start to play with TrustZone Address Space Controller and add tests that ensure that the configuration of that system IP behaves as expected.

Final words

I hope this post gave a useful  introduction to xtest and explained how we are testing OP-TEE. xtest sources  is also a good source to look at if you want to know more about how to write Trusted Applications and how to use the GlobalPlatform APIs. We are continuously adding tests and hopefully sooner than later we will also address the shortcomings mentioned above. But since most of it is open source and thereby freely available, we would be more than happy seeing people with experience in this area getting involved by giving feedback, coming up with ideas and maybe even submitting patches that improve xtest.

Going to BKK16? You will need to know Pathable

Linaro Connect BKK16 is just around the corner and we are expecting another great event.  There will be daily keynotes given by several industry leaders, numerous interesting sessions that attendees will want to participate in, afternoon hacking and a lot of meetings.  So how do you keep track of everything happening each day?  You will need to logon to the very easy to use Pathable event schedule system.  

Pathable allows attendees to see the daily schedule of all activities, select just the ones they would like to attend, schedule meetings, have discussions with other attendees and receive important notices of any changes or additions to the schedule.  It is also where all the content for each session will be posted first, so any links to presentations or videos will be posted under each session as soon as they are available.  

This site will be the place to help you get the most out of your time at Linaro Connect BKK16 so it is really important that you:

1. Go to the site and login prior to the event
2. Set-up your profile and become familiar with the site and how it works
3. There will be a “mobile app” available for you to install from the app store to access the community.  This will be coming shortly.  We will let attendees know as soon as this is available.

Below are some steps to help get you started:

Step 1:  Go to the pathable site:  https://bkk16.pathable.com/

Step 2:  Login – If you have registered for Linaro Connect BKK16  you should have received an email from pathable after 12 February with your login details. This email was entitled: “Please join Linaro Connect Bangkok 2016″. If you cannot find this email please send an email to: connect@linaro.org

Step 3:  Once you get logged in – You will want to update your profile page so that other attendees know who you are, as well as set-up your password to something you can remember easily.  

Step 4:  Add Tags to your profile to identify teams you work with or areas you are interested in.  You can see a list of the current tags being used by going to:  Attendees>Tags (in the left hand drop down), but you can add your own as well.  When people perform a “search” in the attendees or members list, they will be able to choose from the networking interests and tags you and the rest of the community have added to their profiles.

Step 5:  Review the current schedule https://bkk16.pathable.com/meetings  and add sessions you would like to attend to your schedule https://bkk16.pathable.com/meetings/my.  

• Click the Schedule tab
• Hover your mouse over the session description box that pops up that you would like to select and click the “Add” button that appears.
• If you are on a tablet computer or wish to read more before making your choice, select the name of the session you are interested in. Then click the “Add to My Agenda” button to add the session to your schedule.
• You can then go to the My Schedule page to see your agenda for each day

Step 6:  If you need to have any meetings with other attendees you can also easily set those up through Pathable.  

• Visit the profile page of the person you would like to meet
• Click the Schedule a Meeting option
• If you would like to add additional people to the meeting, type their names into the “Attendees” field
• You will see the schedule and free-busy time for you and the invitees on the right. Use your mouse to select a time that is mutually available.
• Select or enter a Location for your meeting*
• Type “Subject” and “Description” for the meeting to give the invitees background on why you would like to meet
• Click the Send Invitation button.

​Your recipients will receive an email notification for the meeting with the option to accept or decline your request. You will receive an email notification when they have responded.

*Once meeting rooms are booked, there are still many areas around the hotel to meet.  There is the option to have your attendees meet at the registration desk or put in your own location.  If you need a specific room please see the registration desk.

For more help with Pathable:

These are the basics for Pathable however, there is much more you can do with the tool; including messaging other attendees, having a group chat, adding documents for a sessions etc.  To get more details you can visit the Pathable Knowledge Base to learn more.  http://support.pathable.com/knowledgebase