Wind River Linux 5.X and Intel Gateway Solutions for Iot

Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

EDUCATION SERVICES

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Version 1.0 A

LECTURE GUIDE

Volume 1 of 2 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

LECTURE GUIDE Wind River Linux 5.x and Intel Gateway Solutions for IoT, Version 1.0 A Education Services Production Date: October 2014

Wind River, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see:

http://www.windriver.com/company/terms/trademark.html

Wind River may refer to third-party documentation by listing publications or providing links to third-party Web sites for informational purposes. Wind River accepts no responsibility for the information provided in such third-party documentation.

This document is designed to support the Wind River Linux 5.x and Intel Gateway Solutions for IoT course. It is not designed as a stand-alone document, nor is it intended as a substitute for documentation that accompanies Tornado, VxWorks, or Wind River Workbench or any other Wind River Systems, Inc. software or hardware product.

http://education.windriver.com Education Services Department Wind River Systems, Inc. 500 Wind River Way, Alameda, CA 94501 510-748-4100 (phone) 510-749-2454 (fax) E-mail: [email protected] For training outside of North America, please contact your local sales ofﬁce. Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Contents

Course Prerequisites vii

Course Objectives viii

1 Wind River Linux Build System 1

2 Working with Packages 43

3 Working with Templates and Layers 77

4 Introduction to IDP 113

5 IDP Architecture 139

6 Secure Remote Management Basics 169

7 Veriﬁed and Secure Boot 211

v Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Course Prerequisites

• General prerequisites: – Basic understanding of embedded operating systems and debugging techniques – Functional knowledge of Linux in a command-line environment – One year of C or C++ programming experience on Linux/UNIX

Wind River Education Services vii Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Course Objectives

By the end of this course you will be able to: • Configure, build, and validate a Wind River Linux kernel and file system • Use layers and templates effectively • Install and build run-time and kernel packages • Understand the IDP architecture, the major IDP components, and their interactions • Create and customize IDP images • Develop IDP-compatible applications

viii Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

1 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

2 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Objectives

By the end of this chapter you will be able to: • Understand the basic concepts of the Wind River Linux build system • Understand the steps involved in building a Wind River Linux Platform project • Create and build your own Wind River Linux Platform project • Effect quick changes to your target file system

Wind River Education Services 3 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

4 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Overview

• The build environment is considered as the directory containing a Wind River Linux Platform project. – Throughout this training, we refer to this directory as $TARGET_BASE – Can be located anywhere you have write access – Projects created in Workbench are usually located in the workspace directory • The build environment is customized to your project, based on the parameters you choose when you initially create it. – All the build activity for a particular project takes place here – You can modify your build environment as you see fit

• $PROJECT_DIR must be writeable

Wind River Education Services 5 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Overview (cont’d)

• This is in contrast to the development environment, which contains the installed Wind River product. – The location of the development environment is determined by the individual who installed the product – By default, the Wind River software installation utility uses $HOME/WindRiver/wrlinux-5 – Throughout this training, we refer to this directory as $WIND_BASE • The development environment should not be modified by developers – One exception: Workbench by default locates workspace in $HOME/WindRiver/workspace

In the lab environment provided with this course, the development environment is located at wr-path/WindRiver.

6 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

Wind River Education Services 7 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Creating the Build Environment

• To begin developing a Wind River Linux Platform, you must first create a build environment using parameters that are characteristic of the device you’d like to target. • There are two ways to establish a new build environment – Command-line interface: using the command-line configure script, included with the Wind River Linux product installation. – Wind River Workbench: the Wind River Linux Platform Project wizard allows you to create a new build environment (which actually uses configure to generate the build environment)

--enable-board

--enable-kernel Build configure Image --enable-rootfs Environment

etc

8 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Creating the Build Environment (cont’d)

• The configure script, found in the $WIND_BASE/wrlinux, supports a large number of command-line arguments – The following settings are mandatory:

Option Example Usage Effect

Specify the BSP for the board you --enable-board --enable-board=qemux86_64 are targeting.

Select a base user-space around --enable-rootfs --enable-rootfs=glibc_small which to model your build environment rootfs.

Select a profile for your build --enable-kernel --enable-kernel=standard kernel environment.

The –help command provides an exhaustive list of all supported options.

Wind River Education Services 9 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Creating the Build Environment (cont’d)

• Other commonly used configure options include:

Option Example Usage Effect Show an exhaustive list of --help --help options available. Specify additional layers to include. Layers provide content --with-layer --with-layer=examples/lemon_layer which can be incorporated into your build environment. Specify a bitbake cache directory. Caching bitbake --with-sstate-dir --with-sstate-dir=$HOME/sstate objects this way can speed up subsequent builds dramatically. Include additional templates. --with-template --with-template=feature/usttrace_demo Templates add features to your user space and/or kernel.

10 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Creating the Build Environment (cont’d)

• Workbench can also be used to establish a new build environment, by creating a Wind River Linux Platform Project. – Workbench uses the configure script to generate the build environment – The generated build Workbench tells you the command environment is found in a it will use to create the build directory named environment. _prj within the workspace

When generating a new Wind River Linux Platform Project in Workbench, two new directories are created in the workspace. Suppose, for example, we create a new project called foo:

• The directory foo is created, which contains information about the project. This directory is used only by Workbench. • The directory foo_prj is created. This contains the actual build environment, as if it were created from the command-line using conﬁgure (which, in fact, it was).

Wind River Education Services 11 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

How Configure Works

• What does $WIND_BASE/wrlinux/configure do? – Bootstrap script which unpacks standard Wind River layers, which are shipped as bare git repositories – Invokes the main configure script, found it the wrlcompat layer • Main configure script then: – Creates a directory structure representing the build environment – Sets up symbolic links, Makefiles, etc that wrap the bitbake build system – Invokes the bitbake project creation command

12 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Wind River Linux and GIT

• Git is a Source code management (SCM) tool – Written by Linux Torvalds for managing kernel.org code – git has enjoyed widespread adoption in many other projects – Architected as a distributed SCM, where each user maintains their own copy (or clone) of the entire repository TRADITIONAL CENTRALIZED SCM GIT ARCHITECTURE

Git Repository User

Repository User User Clone Clone User

Server User User Clone

With git:

• Transactions (like check-ins and check-outs), operate on the clone. • Changes (referred to as commits) are identiﬁed by globally unique commit IDs. • Commits can be shared between repositories by operations (known as pulling and push- ing). • Contrast this to centralized SCMs like CVS or SVN, which maintain a single copy of the repository on a central server.

Wind River Education Services 13 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Wind River Linux and GIT (cont’d)

• Several components of Wind River Linux are delivered as a bare git repositories – Layers (containing recipes, patches, and configuration information) are each packaged in their own repository – Linux kernel source is also packaged its own downloads repository foo.git • Bare repositories contain the database but no

working copy foo.bb foo-1.0.tar.gz – Cannot directly view a bare repository – When you create a new project, configure clones the repository, creating a local working copy

14 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

Wind River Education Services 15 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Build Environment Structure

• Wind River Linux platform project provides a convenient wrapper for a Yocto bitbake build environment – Many directories contain links into the bitbake_build directory

From the Yocto project

16 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Build Environment Contents • There are several important files and directories to be aware of in your build environment:

Component Description bitbake The bitbake build tools

bitbake_build Where all the sources are unpacked, built, installed, and packaged

build Links to build directories for target packages

build-tools Links to build directories for host packages Captures configuration settings, useful when the need arises to re-run config.log configure config.sh A BASH shell script containing build configuration information. Output of the build, including: target file system and images, kernel images export and modules, binary RPMs used to build the target file system image, SDK for building applications, etc.

Wind River Education Services 17 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Build Environment Contents (cont’d) • More files and directories to keep in mind:

Component Description Links to tools required to build the project are found in this directory, host-cross including the toolchain (compilers, linkers, etc) and host tools (git, RPM, ccache, etc). A link to , the primary project configuration local.conf bitbake_build/conf/local.conf file. A link to the Yocto repositories delivered with the Wind River Linux product git installation. Contains local copies of all the included layers extracted from their layers respective git repositories layer_paths Reference file listing all layers included in project. pkglist Reference file listing all target packages included in image. template_paths Reference file listing all templates enabled in project.

toolslist Reference file listing all host packages used by build.

host-cross/bin holds a number of utilities which you might ﬁnd useful when working with your projects. In there, you’ll ﬁnd things that you may not otherwise have installed on your host, like git or qemu, for example.

18 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

Wind River Education Services 19 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Building the Project

• Building a Wind River Linux Platform project involves building both the kernel and the target file system. – The default make rule (synonymous with the fs and build-all targets) builds the kernel and the file system image • An optional rule export-sdk builds the application development SDK – Project level build rules are available in the Workbench project explorer view, or via make help on the command-line

• We will treat kernel builds separately in a dedicated module

20 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Building the Project (cont’d)

• The bitbake build has several tasks that are done for each package in the project. – Each task (or step in the build) can be invoked individually – If no task is specified all build steps are done • Commonly used package tasks: – patch: prepare package for building (or customization) – compile: build the package – package: build the binary RPM – clean: clean the build state – cleansstate: bitbake equivalent of distclean; clean build state and remove any objects associated with this package from the bitbake cache

• You can also invoke these tasks directly in the bitbake shell

Wind River Education Services 21 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Building the Project (cont’d) • Additional tasks include:

Task Description

fetch Obtains (downloads if necessary) the package

unpack Extracts the sources into the build directory

configure Configures patched source in preparation for a build.

install Copies files into staging directory tree

package_write Extracts RPM package files into filesystem

populate_sysroot Extracts RPM package files into sysroot

conﬁgure task has different meanings. For example:

• For autotool packages, runs configure script. • For kernel, builds a sane .config file. • For some packages, this task is a no-op.

22 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Building the Project (cont’d)

• All packages are built from source before they can be installed. – Depending on the rootfs chosen, this can take a considerable amount of time and disk space. • All sources can be found within $WIND_BASE/layers – Check downloads subdirectory of each layer • Package sources are typically delivered: – As a compressed tarball installdir/wrlinux-5/layer_name/downloads/package-#.#.#.tar.* – In a git tree installdir/wrlinux-5/git/package.git installdir/wrlinux-5//layers/layer_name installdir/wrlinux-5/layers/layer_name/package.git installdir/wrlinux-5/layers/layer_name/package/git

• Git trees from the Yocto project, including tools are in the /git directory.

• Git trees provided by Wind River are in the layers directory. • A git tree can be:

– A layer (that is, the only content in the layer). – A package in a layer, in which case it is in a subdirectory of the layer. – A component of a package, in which case it is often in a directory called git.

Wind River Education Services 23 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Building Packages from Source 1. The recipe file (*.bb) and any patches

are checked out from the layer $PROJECT_DIR repository into the project directory – Done when project is created – Recipe controls the build process for the layers/ package – Layers and templates can overlay on top recipes-foo downloads of pre-existing recipes, and can add patches or modify configuration 2 2. The source location is identified foo foo-1.0.tar.gz – Typically found in the directory downloads 1 of an included layer foo_1.0.bb – Often found in the same layer although this is not a requirement

24 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Building Packages from Source (cont’d)

3. Package build directory is populated

with source from downloads $PROJECT_DIR directory – Can optionally download from upstream source over the network layers/ build 4. Patches are applied from package

recipe tree recipes-foo downloads foo-1.0-r1 5. The package is configured and built 3 5 according to the recipe foo foo-1.0.tar.gz foo-1.0

foo_1.0.bb foo-1.0

.patch

../build/foo-1.0-r1 is a symbolink link which points to ../bitbake_build/tmp/work/-wrs-linux/foo-1.0- r1

Wind River Education Services 25 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Building Packages from Source (cont’d) 6. The package is “installed” into

the image staging directory $PROJECT_DIR 7. The install selectively copies files into staging package export build directory – Multiple packages may be created for

standard, docs, and debug images RPMS foo-1.0-r1 – A separate packages may be created for the SDK sysroot 7 6 8. The package staging directory is package image foo-1.0 packaged into a binary RPM 8 foo--1.0-r1..rpm

26 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Assembling the File System

1. Bitbake builds all needed packages 2. Bitbake builds the file system image $PROJECT_DIR – Uses recipes to build the image, just like

it uses recipes to build packages export – Installs binary RPMs into staging area – Runs file system finalization scripts 1 3 (changelist.xml and fs_final.sh) from RPMS images dist layers and templates 2 – Results are captured into an archive $IMAGE-$BSP.tar.bz2 3. Wind River Linux scripts then extracts that archive to export/dist – Also builds any additional requested boot images

• The functionality providing file system finalization scripts are not part of stock Yocto Project. • Rather, they are hooked in by the Wind River Linux image recipes, which build on top of oe-core’s. Note that these steps are performed in a pseudo (fakeroot) environment. export/RPMS points to bitbake_build/tmp/deploy/rpm export/bsp-filesystem-type-dist.tar.bz2 points to bitbake_build/tmp/deploy/images/wrlinux-image-filesystem-type-bsp.tar.bz

Wind River Education Services 27 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

File System Finalization

• This stage allows for final adjustments to the target file system that are difficult or impossible to do otherwise. – Typical cases are removing files or directories that you don’t need, since the build system only operates at package-level granularity • Two mechanisms available: changelist.xml and fs_final.sh • Highlights of changelist.xml: – XML file format – Limited functionality: adding, removing, or changing attributes of files, directories, symbolic links, device nodes, and pipes • Highlights of fs_final.sh: – Shell script format – Flexible

• Default locations are in local.conf • WRL_CHANGELIST_PATH = $PROJECT_DIR/layers/local/conf/image_ﬁnal • WRL_FS_FINAL_PATH = $PROJECT_DIR/layers/local/conf/image_ﬁnal

28 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Boot Images • Wind River Linux supports generation of boot images in a number of popular formats – Can select one (or more) using --enable-bootimage option – Can also edit local.conf to select formats Format Description tar.bz2 Compressed archives that can be extracted directly into tar.gz formatted file system or exported NFS directory Bootable ISO9660 image which can be burned onto an live optical disk or booted directly using QEMU Ext3 file system image which can be written directly to a ext3 Linux partition JFFS2 file system image which can be written to an MTD jffs2 flash partition. UBI file system image which can be incorporated into a flash ubifs volume maintained by the UBI infrastructure.

Wind River Education Services 29 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Pseudo

• Generating file system images requires root privileges – Must create files or directories owned by root (like /etc/passwd for example) – Must create pipes and/or device nodes (like /dev) • Problem: running tools should not require root privileges • Solution: any tools that manipulate target file system run in a “fake root” environment called pseudo

Conventional Linux User-space Pseudo Environment

Kernel UID!=0 Kernel UID!=0 glibc glibc pseudo remaps to creat()

mknod()  mknod()  EPERM EOK Process Process

In the usual unmodiﬁed case:

• Process runs as a regular user

• Process calls the C-function mknod(), which C library maps to a system call • The kernel, seeing that the originating process does not have sufficient permissions to perform this operation, rejects it In pseudo: • Process calls the C-function mknod(), which the pseudo layer (a thin layer in front of C library) remaps to creat() • C library maps creat() to a system call. • The kernel grants the request since process is allowed to create files here • Pseudo “remembers” that this request was actually to satisfy mknod(). When file attributes are requested at a later time, pseudo will intercept with this information

30 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Pseudo (cont’d)

• Pseudo uses a database to remember information about the operations it fakes out – This is why generated file systems do not look right when viewed outside of the pseudo environment – Must be within pseudo to see file ownerships and attributes as they were meant to be

You can become the pseudo root user with project/scripts/fakestart.sh

Wind River Education Services 31 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Pseudo (cont’d)

Conventional Linux User-space • Pseudo is an integral part of file $ ls –l dev -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 console -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 dsp system generation -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 full -rw-r--r-- 1 fedora fedora 0 2009-01-06 22:24 kmem -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 mem – It is needed to generate an authentic -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 mixer -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 null -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 port file system structure -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 ptmx drwxr-xr-x 2 fedora fedora 4096 2009-01-06 22:24 pts -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 ram – Without a fake root environment, -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 ram0 -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 ram1 would need to actually be root, which -rw-rw-rw- 1 fedora fedora 0 2009-01-06 22:24 random … poses a security risk – Pseudo is not risky, since processes Within Pseudo Environment #ls –l dev still operate within the context and crw-rw-rw- root/root 5,1 2009-01-06 22:24 console crw-rw-rw- root/tty 14,3 2009-01-06 22:24 dsp crw-rw-rw- root/root 1,7 2009-01-06 22:24 full limits of a conventional Linux process crw-r--r-- root/kmem 1,2 2009-01-06 22:24 kmem crw-rw-rw- root/kmem 1,1 2009-01-06 22:24 mem crw-rw-rw- root/tty 14,0 2009-01-06 22:24 mixer • Remember that viewing such a crw-rw-rw- root/root 1,3 2009-01-06 22:24 null crw-rw-rw- root/kmem 1,4 2009-01-06 22:24 port crw-rw-rw- root/tty 5,2 2009-01-06 22:24 ptmx file system (ie ) drwxr-xr-x root/root 0 2009-01-06 22:24 pts/ export/dist brw-rw-rw- root/disk 1,1 2009-01-06 22:24 ram brw-rw-rw- root/disk 1,0 2009-01-06 22:24 ram0 requires the pseudo environment brw-rw-rw- root/disk 1,1 2009-01-06 22:24 ram1 crw-rw-rw- root/root 1,8 2009-01-06 22:24 random …

• Try this for yourself in the lab: examine the contents of the export/dist directory of a project that has been built, using the command ls –l export/dist. • Now try it in pseudo:

– Run pseudo yourself: from the root directory of your project, run the command script- s/fakestart.sh – Normally, pseudo takes as its ﬁnal argument a command to run in the pseudo environment. In the absence of that argument, it starts a sub-shell within the pseudo environment. – Play around with your “root shell”. Run the command ls -l export/dist. – When done, type exit to return to your regular shell.

32 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Agenda

Wind River Linux Build System

• Overview • Creating the Build Environment • The Build Environment • Building the Project • Optimizing the Build

Wind River Education Services 33 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Optimizing the Build

• Because everything is built from source, builds can take a lot of time. Fortunately, many optimizations are available: – Shared state cache: caches objects related to the various tasks that bitbake performs. Enabling a shared state cache can significantly reduce build times. – Parallelism: enables multiple tasks to be run concurrently. This feature is particularly beneficial on multi-core systems. – ccache: integrates with the compiler to cache compiled objects, yielding a modest performance boost.

34 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Shared State Cache

• Setting up shared state cache can be done a number of ways – Globally: set the SSTATE_DIR environment variable to point to the cache directory. This will apply to every project you build thereafter. – When configuring a project: use the --with-sstate-dir option to specify the cache directory for that project. – After configuring: edit the setting of SSTATE_DIR in local.conf, prior to building the project. – After building: bitbake will automatically maintain an internal cache in bitbake_build/sstate-cache; manually copy the objects in that directory to the external cache directory.

• $HOME/.proﬁle is a good place to set your **SSTATE_DIR ** so that it is applied globally

Wind River Education Services 35 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Parallelism

• There are two settings to control parallelism in the build – Parallelism at the level of bitbake – Parallelism at the level of make • To control bitbake parallelism: – When configuring a project: use the --enable-parallel-pkgbuilds option to specify the maximum number of bitbake tasks that can be executed in parallel – After configuring: edit the setting of BB_NUMBER_THREADS in local.conf

This value should not exceed the number of available cores in your system.

36 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Parallelism (cont’d)

• To control make parallelism: – When configuring: use the --enable-jobs option to specify the maximum number of jobs that make can perform in building a single package. – After configuring: edit the setting of PARALLEL_MAKE in local.conf. – At build time: set MAKE_JOBS in your invocation of make to make a temporary adjustment to this value This value is used in Applies to the “outer” building the individual make. packages.

$ make fs MAKE_JOBS=-j10 -j1

Wind River Education Services 37 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Compiler Cache

• Setting up a compiler cache is similar to shared state cache – Globally: set the OE_CCACHE_DIR environment variable to point to the compiler cache directory. – When configuring a project: use options --enable-ccache =yes and --with-ccache-dir option to specify the cache directory for that project. You can also set the maximum size of the cache using --with-ccache-size. • You can view your compiler cache statistics by performing the following:

$ CCACHE_DIR=… ccache -s

Compiler cache should be on the same file system as the project to achieve a performance benefit.

• $HOME/.proﬁle is a good place to set your **OE_CCACHE_DIR ** so that it is applied globally

38 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Questions

1. What are the two ways to invoke configure? 2. What option is used to add a layer to your project? 3. What editable file contains important configuration information regarding your project? 4. Where can you find an extracted copy of the target file system? 5. How would you quickly get a new file into the /etc directory on the target file system? 6. What are two example file system operations where pseudo is needed?

1. Configure can be invoked directly from the command line, or by creating a Wind River Linux Platform Project in Workbench. 2. –with-layer 3. local.conf 4. export/dist 5. Use an fs_final.sh or add the item to changelist.xml in your local layer. 6. Making device nodes, and manipulating file ownerships.

Wind River Education Services 39 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned to: • Understand the basic concepts of the Wind River Linux build system • Understand the steps involved in building a Wind River Linux Platform projects • Create and build your own Wind River Linux Platform project • Effect quick changes to your target file system

40 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux Build System

Wind River Education Services 41 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

42 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

43 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Packages

• Overview • Build Life Cycle • Managing Packages • Recipes

44 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Objectives

By the end of this chapter you will be able to: • Describe packages, and how they apply to the build environment versus the target image • Add a package to the target image • Integrate a new package into your build environment

Wind River Education Services 45 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Packages

• Overview • Build Life Cycle • Managing Packages • Recipes

46 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Overview

• A package provides all the resources related to a specific software component. • Packages are defined by several components: – a recipe (.bb file) that tells the build system (BitBake) how to build the package – that provides the code upstream source Build System that implement the package – optional patches that the build system applies prior to building to fix bugs or build issues Recipe

Patches

Source Package

Wind River Education Services 47 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Overview (cont’d)

• Recipes and patches are packaged in layers. • Package source can be delivered in a couple of different ways: – directly from the upstream source (over the network).This is typical of most standard layers found in the OpenEmbedded community. – local cache (PREMIRROR). Wind River Linux uses this mechanism to include source in shipped product.

FTP HTTP OpenEmbedded Source Git Recipe Patches Subversion Layer

Wind River Linux Source Recipe Patches Layer

Network fetching supports a number of different protocols (FTP,HTTP,or revision control systems like Git or Subversion).

48 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Overview (cont’d)

• You can use append files to modify packages. – Append files add to an existing recipe. – Enables package build configuration to be modified from other layers

FTP HTTP Layer Providing Source Git Recipe Patches Subversion Package

Layer Modifying Append File More Patches Package

Recipe + PatchesMore + MoreMore Patches Resulting Append File MorePatches Patches Source Contents Patches Package

Network fetching supports a number of different protocols (FTP,HTTP,or revision control systems like Git or Subversion).

Wind River Education Services 49 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Overview (cont’d)

• Packages come in two flavors: – Host (native) packages provide tools needed to build your image. Some examples include: • bison (generates parser code) • elfutils (to manage compiled objects) – Target packages constitute the software that you will deploy to your device. Some examples include: • BusyBox (reduces the footprint used by common utilities) • util-linux (standard utilities) • Some packages function in both roles. – Use rpm on the host to build the target file system, or on the target to manage run-time packages. – Many host tools and target packages use shared libraries (like zlib).

50 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Agenda

Working with Packages

• Overview • Build Life Cycle • Managing Packages • Recipes

Wind River Education Services 51 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Build Life Cycle

• Packages are built by executing a sequence of tasks. – dependencies dictate the task order, BitBake manages it • The tasks generally execute in the following order: 1. fetch downloads package source 2. unpack extracts package source into build staging area 3. patch applies any available patches to the extracted source 4. configure prepares the source for the cross compile environment 5. compile builds the source 6. install installs the built result to a staging area representing the target file system 7. package prepares installed files for packaging 8. package_write_rpm packages files into binary RPMs

52 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Fetching the Source

• The fetch task downloads the package source (if needed). – The directory bitbake_build/downloads caches the downloads. • You can avoid downloading if: – source already exists in bitbake_build/downloads – source exists in PREMIRRORS – BB_NO_NETWORK is set to 1 (typically in local.conf)

• PREMIRRORS variable can short- circuit the fetch task $TARGET_BASE • Source used in place BB_NO_NETWORK=0 • Wind River Linux layers use bitbake_build PREMIRRORS to avoid downloading; upstream source is kept in the downloads directory of the layer downloads

Wind River Linux disables network downloading by default (by setting BB_NO_NETWORK=1 in local.conf).

Wind River Education Services 53 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Unpacking the Source

• The unpack task extracts the package source. – BitBake extracts the source into a staging area whose location depends on whether package is being built for the host or target.

Recipes can use the variable ${S} to $TARGET_BASE downloads zlib-1.2.7.tar.bz2 reference this build stage.

bitbake_build tmp Stage for zlib source as a package zlib-native-1.2.7-r1 host work Some packages (like Stage for zlib source the one shown here) are as a package zlib-1.2.7-r1 target built as both host and target packages.

Recipes can use the variable ${S} to refer to the directory containing unpacked source.

54 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Patching the Source

• BitBake applies patches (if any) to the extracted source. – bug fixes or enhancements that are not yet upstream – resolve cross-compile issues • Patches let the build system use pristine upstream source, while still addressing build issues or run-time bugs. • Patches are gathered from layers. – declared by recipes and append files by manipulating the per- package variable SRC_URI

Example Excerpt from Recipe Example Excerpt from Append File

SRC_URI = "http://…/mpatrol-1.5.1.tar.gz \ file://x86_64-support.patch \ SRC_URI += "file://rpm2cpio_segfault.patch" file://mips-fixes.patch \ …

Patches are generally organized into the same directory as the corresponding recipe or append ﬁle, or (more often) one directory below.

Wind River Education Services 55 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Configuring the Source

• The configure task configures the extracted source before building. – prepares the source for cross compilation • For many packages, this task is a no-op, with the following notable exceptions: – Packages driven by the GNU build system (inherit autotools) run their configure script to set up Makefiles, header files, and other configuration files for the cross-compile environment. – The kernel (linux-windriver) builds its .config file. – The BusyBox configuration file (.config) is prepared.

56 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Building the Source

• The compile task builds the source. • Target packages use: – the target tool chain – the target sysroot (to address build-time dependencies) • Host packages use: – a cross tool chain appropriate for the host architecture (but not the native one) – the host sysroot (to provide utilities, libraries, and headers needed by the build) • Most packages build in place, while some redirect build output to a separate staging area. Recipes can use the variable ${B} to reference the build stage. For most packages, ${B} is the same as ${S}.

The kernel (linux-windriver) is an exception to the above rule; it builds in a separate staging area.

Wind River Education Services 57 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Installing Build Output

• After building the source, the install task captures output. – Copies useful build output and material (executables, libraries, configuration files, etc.) into another separate staging area. • For target packages, this area represents the target file system. • For host packages, this area represents the host sysroot.

Main stage for the zlib target package zlib-1.2.7-r1

Directory containing extracted, patched, configured, and built source zlib-1.2.7 Subset of build output (for example, shared and static libraries, header files, man pages, debug info) image

• For many packages, this amounts to a call to make install

58 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Preparing a Package

• Installed content is then prepared for packaging via the package task. – Local copy is taken for processing – Processes content: strips executables, normalizes file permissions, adjusts shared library names, etc – Builds package metadata (dependencies and provides)

Main stage for the zlib target package zlib-1.2.7-r1

Directory containing extracted, patched, configured, and built source. image Subset of extracted material and build output; in this example, libraries (shared and static), header files, man pages, debug info. package

Wind River Education Services 59 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Preparing a Package (cont’d)

• Package splitting occurs as part of the package processing stage. – Breaks down target packages into finer-grained units, allowing for a reduced image footprint.

zlib-1.2.7-r1

package packages-split

zlib zlib-dev zlib-dbg zlib-doc zlib-staticdev

libz.so /usr/include/* /lib/.debug/* /usr/src/debug/* /usr/share/man/* libz.a

60 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Creating a Binary Package

zlib-1.2.7-r1 • The package_write_rpm task is the last step in packages-split deploy-rpms building the package. zlib libz1-1.2.7-r1.rpm – generates a binary RPM for each split package – uses the content and zlib-dev libz-dev-1.2.7-r1.rpm metadata gathered by the task package zlib-dbg libz-dbg-1.2.7-r1.rpm • These RPMs are ultimately copied over to zlib-doc libz-doc-1.2.7-r1.rpm the package feeds.

Wind River Education Services 61 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Logging

• BitBake maintains extensive logs for each task it executes.

zlib-1.2.7-r1 Log files are saved in the subdirectory temp in the package staging area. temp

This file records tasks in the order they were executed, along with pointers to associated log files. log.task_order This file provides a symbolic link to log file for most recently executed task. log.do_compile compile

Logs output for the compile task (might be several entries for multiple builds) log.do_compile.*

do_compile Logs commands executed to fulfill the corresponding task run.do_compile.*

62 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Agenda

Working with Packages

• Overview • Build Life Cycle • Managing Packages • Recipes

Wind River Education Services 63 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Adding Packages

• There are a few ways to add packages to your image: – Use the --with-package option when configuring the build environment:

configure … --with-package=gdb

– Use the addpkg option provided by the Wind Works for Wind River Linux Makefile wrapper: River Linux only. make -C build gdb.addpkg

– Add to IMAGE_INSTALL in configuration file (local.conf or default-image.bb): Works for Wind River Linux or IMAGE_INSTALL_append += "gdb" OpenEmbedded.

Adding packages may pull in additional dependencies.

64 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Removing Packages

• For packages added using --with-package or addpkg: – Packages can be removed using rmpkg:

make -C build gdb.rmpkg Works for Wind River Linux only. – Or, remove the line from configuration file that modifies IMAGE_INSTALL: Works for Wind IMAGE_INSTALL_append += "gdb" River Linux or OpenEmbedded.

Wind River Education Services 65 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Integrating New Packages

• Importing a package is usually straightforward. • High level steps are: – making source available to the build system – creating a recipe that tells BitBake how to build it – patching sources to fix build issues that you cannot fix by modifying the recipe • Key challenges can include: – proper invocation of cross compile tools – propagating sysroot to cross-compile tools – appropriate packaging of binaries and additional support files – satisfying build dependencies of more complex packages

66 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Integrating New Packages

• The import-package tool automates some of the basic steps: – downloads source and installs into the local layer – creates a basic recipe customized for your package name and version • Then you must finish the recipe.

Wind River Education Services 67 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Packages

• Overview • Build Life Cycle • Managing Packages • Recipes

68 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Recipes

• BitBake recipes follow Python syntax. • A recipe for a package can be made up of several files: – package_version.bb — the main, version-specific recipe that BitBake looks for to build a package (for example, acl_2.2.51.bb) – package_version.bbappend — a version-specific extension to an existing recipe, usually provided by a layer, to modify a package build (for example, bind_9.8.bbappend) – package.inc — used to capture version-independent configuration information; these are sourced by different versions of the same recipe (for example, binutils.inc)

require acl.inc PR = "r3" SRC_URI[md5sum] = "3fc0ce99dc5253bdcce4c9cd437bc267" SRC_URI[sha256sum] = "06854521cf5d396801af7e54b963668…"

• The example shown is acl_2.2.51.bb. • Notice that it only speciﬁes the checksums of the tarball. The remainder of the recipe is in acl.inc.

Wind River Education Services 69 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Recipe Metadata

• The initial required part of a recipe provides important information to identify the package.

SUMMARY = "Very high-quality data compression program." License identification filters out DESCRIPTION = "bzip2 compresses files using the Burrows- undesirable packages Wheeler.. Huffman coding. Compression is generally considerably better than.. LZ77/LZ78-based compressors, and approaches the performance of the.. HOMEPAGELicense checksum= authenticates "http://www.bzip.org/" license text SECTION = "console/utils" LICENSE = "BSD-4-Clause" LIC_FILES_CHKSUM = Package revision can track recipe file://LICENSE;beginline=8;endline=37;md5=4eb05..revisions PR = "r5" SRC_URI = "http://www.bzip.org/${PV}/${BPN}-${PV}.tar.gz \ file://configure.ac \ Package source URL(s) usually file://Makefile.am" includes an upstream URL

70 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Recipe Metadata (cont’d)

• All other information in a recipe is optional. You can override, prepend, or extend the default.

PACKAGES =+ "libbz2 libbz2-dev libbz2-staticdev"

Declare additional packages (for example, force a package split into

libbz2, libbs2-dev, and libbz2-staticdev)

CFLAGS_append = " -fPIC -fpic -Winline -fno-strength-reduce…

Append to compile flags passed in by the build system

FILES_libbz2-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV}"

Specifies files that go into the package libbz2-dev

Wind River Education Services 71 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Declaring Dependencies

• Bitbake determines some dependencies automatically. – BitBake can usually detect shell or shared library dependencies. • Dependencies can be explicitly declared in recipes. – DEPENDS indicates a build-time dependency. BitBake must build these dependencies before it builds this package.

DEPENDS = "flex"

– RDEPENDS indicates a run-time dependency that you must include in the target image (but this does not influence the build scheduling).

RDEPENDS = "cool-ttf-fonts"

72 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Implementing Tasks

• Tasks can be inherited from classes. Also, they can be: – augmented – overridden entirely

inherit autotools Inherit the autotools class, which abstracts functionality to deali with do_configure_prepend () { packages driven by configure cp ${WORKDIR}/configure.ac ${S}/ … Perform additional actions before } executing the default configure task

defined in autotools do_install() { oe_runmake 'DESTDIR=${D}' install } Replace the default install task entirely

Wind River Education Services 73 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Questions

1. What is the difference between a host package and a target package? 2. What two required components constitute a package? 3. What scripting language is used to implement a package recipe build system?

1. A host package is used by the host and forms part of the build environment. A target package is used by the target, and forms part of the target image. 2. the source and a recipe ﬁle 3. Python

74 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Packages

Review

In this chapter you learned to: • Describe packages, and how they apply to the build environment versus the target image • Add a package to the target image • Integrate a new package into your build environment

Wind River Education Services 75 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

76 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

77 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Templates and Layers

• Overview • Layers • Templates • Layer and Template Processing

78 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Objectives

By the end of this chapter you will be able to: • Know why and how templates are used • Use templates to customize your platform build • Know how and why layers are used • Use layers to extend your development environment

Wind River Education Services 79 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Templates and Layers

• Overview • Layers • Templates • Layer and Template Processing

80 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Overview

• The Wind River Linux build system has always been built around the central concepts of layers and templates. • Layers are intended to provide a consistent interface for extending the development environment. – Layers provide tools and resources that can be used to configure and build your project. – Layers are a bitbake construct, and can be interchanged with any Yocto-compliant project • Templates provide a consistent interface for customizing the build environment. – Templates deliver configuration information which modifies your platform project image in some way. – Templates are unique to Wind River Linux.

• Layer support has always been designed into Wind River Linux products prior to 5.0, but the layering support in 5.0 is provided by bitbake

Wind River Education Services 81 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Working with Templates and Layers

• Overview • Layers • Templates • Layer and Template Processing

82 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Layers

• A layer functions as a container for templates and other resources used by the build system. • Layers allow you to isolate different types of customizations from each other. – BSP layers are used to manage machine-specific configuration information. – Distribution layers are used to manage policies related to your platform project distribution, and are typically abstracted by the build system. – Basic or application layers are used to manage applications and packages required by your project.

• Previous versions of Wind River Linux did not classify layers in this fashion. BSPs were implemented using templates. • Most developers will usually work with basic layers.

Wind River Education Services 83 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Wind River Linux Standard Layers

• Wind River Linux includes the following standard layers in every Wind River Linux platform project: • wrlinux: this is a distribution layer which contains Wind River Linux policy-related definitions

• wrlcompat: this layer implements the Wind River Linux front-end to the underlying Yocto Project build system

• wr-toolchain: this layer provides integration for the Wind River-provided binary toolchain

• oe-core and oe-core-dl: together these contain current versions of OpenEmbedded core material (metadata, source code, etc)

• These can be found in $WIND_BASE/layers, although layers are packaged in the product installation as bare git repositories • To see the layer contents, you can manually check them out using git, or they can be seen in the layers subdirectory of a conﬁgured project

84 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Wind River Linux Standard Layers (cont’d)

• wr-kernel: this layer provides integration for the Wind River-provided kernel source and BSPs

• wr-bsps: not a layer in itself, but rather a placeholder directory containing the BSP layer corresponding to the selected target board

• wr-base: this layer contains many of the components (primarily recipes and classes) needed to build a Wind River Linux platform

• wr-tools-profile and wr-tools-debug: these layers provide command-line and Workbench tools supporting target debugging and analysis

Wind River Education Services 85 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Example Layers

• Wind River Linux provides the following example layers – These can be included into your project using --with-layer • fs-final: this layer illustrates how perform target file system tweaks, in the context of a Wind River Linux template

• hello-world: this layer illustrates how to build and include a simple executable into the target file system

• kernel-config-example: this layer provides an example of how to manipulate kernel configuration options, in the context of a Wind River Linux template

• lemon_layer: provides applications exercising a number of use cases relating to Wind River Linux-provided tools

• These can be found in $WIND_BASE/layers/examples, although layers are packaged in the product installation as bare git repositories • To see the layer contents, you can manually check them out using git, or they can conﬁg- ured into a project using –with-layer and subsequently can be seen in the layers/examples subdirectory of a conﬁgured project • Can also use –enable-checkout-all-layers=yes to see all layers in your project directory

86 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Local Layer

• Wind River Linux builds a local layer into every platform project • The local layer is a basic layer that allows you to develop content specific to your project – Provides a home for applications or packages unique to your project – Enables you to more easily capture and share changes you’ve made to your project • Can be found in the layers/local subdirectory of any configured platform project

• In previous versions of Wind River Linux, the platform project directory was itself treated as an implied local layer • In 5.0, the delineation between the project directory and local layer is distinct

Wind River Education Services 87 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

How Layers Are Included

When the project is initially configured: • The --enable-board option implicitly selects a BSP layer – This layer resides in the layers/wr-bsps subdirectory • Several layers are included by default – Discussed in previous slide • The local layer is instantiated and included by default • --with-layer can be used to pull in additional layers: – Wind River Workbench UI provides access to this functionality as well

• In previous versions of Wind River Linux, BSPs were maintained in separate layers, although BSPs were really templates; by contrast in 5.0 BSPs are true layers • Can also use –enable-checkout-all-layers=yes to see all layers in your project directory

88 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

How Layers Are Included (cont’d)

After the project is initially configured: • Can re-run configure with the --with-layer option – Best general approach since it works for all types of layers • Can also add additional layers directly into bblayers.conf – Approach does not work for Wind River-provided layers, since these layers are packaged differently – Not suitable for layers which take advantage of Wind River Linux functionality (like templates)

• When running configure,in a previously configured platform project directory, you must: ‒ Ensure that other options match original configuration ‒ Must also include --enable-reconfig option

• Wind River-provided layers are packages as a git repository, and conﬁgure knows how to handle layers packaged in this fashion • conﬁgure also performs other layer pre-processing (for example, scanning for default templates)

Wind River Education Services 89 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

How Layers Are Included (cont’d)

LCONF_VERSION = "5" Included layers are listed in: BBPATH = "${TOPDIR}" • bblayers.conf BBFILES ?= ""

– bitbake configuration file BBLAYERS = " \ – Can edit to add (or remove) layers …/layers/wrlinux \ …/layers/wrlcompat \ – Do not add Wind River-supplied …/layers/wr-toolchain \ layers, use configure instead … /opt/mylayer …/layers/local \ " • layer_paths …/layers/wrlinux \ – Plain text …/layers/wrlcompat \ – This file is for reference only; do …/layers/wr-toolchain \ … not edit /opt/mylayer …/layers/local \

• bblayers.conf is found in the bitbake_build/conf subdirectory of a configured project • layer_paths is found in the top-level directory of a configured project • Unlike the layers file in previous versions of Wind River Linux, layer_paths is considered read-only (it is not read by the build system)

90 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Anatomy of a Layer

• Layers are represented by directories in the file system • Minimum requirement is a layer.conf file • In addition to a configuration file, typical layers contain other resources, such as: – Whole recipes (.bb files) – Amendments to recipes (.bbappend files) – Classes – Source code – Scripts – Configuration files – Templates

Wind River Education Services 91 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Anatomy of a Layer (cont’d)

$LAYER

conf README recipes-* templates

• templates • conf directory • directory • file recipes-* is mandatory README directories contain Wind is required for contain recipes River Linux • Collects layer Yocto project provided by templates configuration compliance information this layer provided by this layer

• If you look at the layers within $WIND_BASE/layers, you will not see this structure • Unlike previous versions of Wind River Linux, layers within the product install are packaged as git repositories and as such are not directly viewable; they are only unpacked when a project is conﬁgured • You will see this structure if you look at the layers within a platform project directory

92 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Anatomy of a Layer (cont’d)

• layer.conf file is $LAYER mandatory • Defines variables used by the build system conf README recipes-* templates‒ Informs build system about layer content ‒ Sets layer-specific

distro machine parameters, such as layer.conf priority • Typically, a standard boilerplate can be used with minimal changes

Wind River Education Services 93 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Anatomy of a Layer (cont’d)

$LAYER • distro directory is used by distribution layers wanting to implement

conf README recipes-* distrotemplates -related policy ‒ Global build settings ‒ Build system policies

layer.conf distro machine • machine directory is used by BSP layers ‒ Hardware-specific kernel configuration

• For an example of the types of things found in a distro layer, check layers/wrlinux/con- f/distro dir in any conﬁgured platform project

94 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Anatomy of a Layer (cont’d)

$LAYER • recipes-* directories are optional

• Contain recipes conf README recipes-* templates provided by the layer

• Often segregated into recipes-bsp different directories by

functionality recipes-connectivity

recipes-core

• These examples are pulled from the wr-kernel layer

Wind River Education Services 95 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Anatomy of a Layer (cont’d)

• templates directory is $LAYER optional • Contains Wind River Linux templates conf README recipes-* templates provided by the layer

‒ default templates are default included automatically ‒ Feature templates are included using --with- feature template

96 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Agenda

Working with Templates and Layers

• Overview • Layers • Templates • Layer and Template Processing

Wind River Education Services 97 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Templates

• A template is a collection of configuration information, aimed at delivering a particular feature. • A template functions like a switch to enable a particular piece of functionality in your platform. • Templates typically do one (or more) of the following: – Add user-space packages in the target file system – Add, remove, or modify files in the target file system – Modify kernel configuration options – Patch the kernel or user-space packages – Modify build settings • Templates are unique to Wind River Linux

• In previous versions of Wind River Linux, layers and templates were completely orthogonal concepts • In Wind River Linux 5, the boundaries between templates and layers has become blurred, since layers can perform all the tasks that templates can • However, templates still provide a convenient mechanism for grouping available resources into features than can be enabled or disabled individually

98 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Templates (cont’d)

• Templates are found within layers, and can be in one of two forms: – Default templates are included automatically when the containing layer is included in the project – Feature templates are available for including when the containing layer is included in the project; these must be included explicitly using --with-template • Templates allow you to isolate functionality provided by a layer into individual features. – Features can be enabled/disabled individually

Wind River Education Services 99 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

How Templates Are Included

• When the project is initially configured: – Default templates from included layers are automatically included – --with-template can be used to pull in optional templates; Wind River Workbench UI also provides access to this functionality • After the project is initially configured: – Can re-run configure using the --with-template option

• Previous versions of Wind River Linux did not support re-running conﬁgure in an already conﬁgured platform project

100 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

How Templates Are Included (cont’d)

• Included templates are listed in local.conf – This is a bitbake configuration file – Although it’s possible to edit this file to add or remove templates, it’s recommended to instead re-run configure

Default templates

… ## Included feature templates require …/layers/wr-kernel/templates/default/template.conf require …/layers/wr-tools-debug/templates/default/template.conf require templates/feature/debug/template.conf

Template included using --with-template=feature/debug

• local.conf is found in the bitbake_build/conf subdirectory of a conﬁgured project, but a symbolic link is created in the top-level directory of the project

Wind River Education Services 101 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Anatomy of a Template

$LAYER • templates are found within a layer

• default templatesconf are README recipes-* templates included automatically when the layer is included default • feature templates must be explicitly included feature $TEMPLATE

102 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Anatomy of a Template (cont’d)

$TEMPLATE

template.conf README

• template.conf file is mandatory • Defines what the template does • README file is not a strict ‒ Add packages requirement, but highly ‒ Manipulate kernel configuration recommended ‒ File system tweaks ‒ Modify build settings

• If you explore templates in your layers, you might see artifacts from previous versions of Wind River Linux

Wind River Education Services 103 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Anatomy of a Template (cont’d)

Other resources commonly found in a template: • changlist.xml and fs_final.sh files: these are used to manipulate the target file system – Add or remove directories, files, device nodes, etc • *.scc files: these are used to patch the kernel or manipulate kernel configuration

104 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Agenda

Working with Templates and Layers

• Overview • Layers • Templates • Layer and Template Processing

Wind River Education Services 105 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Layer and Template Processing

• Layers and templates are processed in similar fashions; build system sources well-defined .conf file – For layers, this file is conf/layer.conf – For templates, file is template.conf • Differences lie in how .conf file is written – template.conf files are typically focused on delivering functionality implementing a particular feature – layer.conf files are typically focused on making additional resources available for the developer to choose from

• Example is taken from the template.conf of feature/kvm template, taken from the wr- kernel layer • This is a good example of the types of things a template typically does; this one enables kernel features, inﬂuences the build conﬁguration (by enabling the build of the ext3 image type), and it adds three user-space packages to the image

106 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Layer and Template Processing (cont’d)

• Consider the following sample layer.conf: # We have a conf and classes directory, add to BBPATH BBPATH := "${LAYERDIR}:${BBPATH}" Add layer directory to the list of paths which bitbake # We have a packages directory, add to BBFILES searches for configuration. BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" Inform bitbake of any BBFILE_COLLECTIONS += "sample-feature" recipes this layer provides. BBFILE_PATTERN_sample-feature := "^${LAYERDIR}/" BBFILE_PRIORITY_sample-feature = "7" Define layer-related # Add scripts to PATH varibles (see notes). PATH := "${PATH}:${LAYERDIR}/scripts"

# We have a pre-populated downloads directory, add to PREMIRRORSAdd scripts this layer PREMIRRORS_append := "\ provides to $PATH. git://.*/.* file://${LAYERDIR}/downloads/ \n \ svn://.*/.* file://${LAYERDIR}/downloads/ \n \ ftp://.*/.* file://${LAYERDIR}/downloads/ \n \ Common boilerplate used http://.*/.* file://${LAYERDIR}/downloads/ \n \ by most layers. https://.*/.* file://${LAYERDIR}/downloads/ \n"

• This example is taken from the hello-world example layer, but can typically be applied to most basic layers (modifying only the layer name references) • BBPATH is used by bitbake to locate bbclass and configuration files • BBFILES maintains a list the recipes used by bitBake to build software • BBFILE_COLLECTIONS defines a namespace for this layer to allow bitbake to organize recipes on a per-layer basis; this setting should be consistent with any other references to the layer name in layer.conf • BBFILE_PATTERN_ is a regular expression used by bitbake to allow it to associate files listed in BBFILES with this particular layer; • BBFILE_PRIORITY_ defines the priority of this layer, enforcing precedence on overlapping recipes. Typical range for this value is between 1 and 10, with 10 indicating the highest precedence.

Wind River Education Services 107 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Layer and Template Processing (cont’d)

• Now consider the following sample template.conf:

SCC files are used to specify kernel configuration options (and patches) # enable kernel patches / configure options KERNEL_FEATURES_append += "features/kvm/qemu-kvm-enable.scc" KERNEL_FEATURES_append += "features/netfilter/netfilter.scc"

# enable build out .ext3 image file, shall be useful for qemu IMAGE_FSTYPES += "ext3"

# add qemu into build Include ext3 file system image as a IMAGE_INSTALL_append += "qemu" product of the build IMAGE_INSTALL_append += "libvirt" IMAGE_INSTALL_append += "socat" Add these user-space packages to the target file system image

• This example is taken from the feature/kvm template, found in the wr-kernel layer • Exemplifies the types of things a template typically does • Note: SCC files are used by the Wind River Linux kernel build system to collect kernel patches and configuration fragments; this is discussed in more detail in the Kernel Devel- opment module

108 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Questions

1. What is the best way to describe the relationship between layers and templates? 2. You have ported a package over to work flawlessly with your Wind River Linux 5.0 build. Should you package this in a layer or a template? 3. Suppose you want to add a file called “hello” (contents are not relevant) to the root directory of the target file system. Do you need to do this in a layer or a template?

1. A container relationship exists; templates are contained by layers. 2. A layer; templates cannot be used to deliver packages. 3. A layer or a template can accomplish this.

Wind River Education Services 109 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned to: • Know why and how templates are used • Use templates to customize your build environment • Know how and why layers are used • Use layers to extend your development environment

110 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Working with Templates and Layers

Wind River Education Services 111 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

112 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to Intelligent Device Platform

113 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Introduction to IDP

• What Is IDP? • Why Use IDP? • How Does IDP Work with Other Products?

114 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Objectives

By the end of this chapter you will be able to: • Describe the IDP environment • Name other products that work with IDP • Identify the roles of the teams that use IDP • Identify situations in which IDP is used

Wind River Education Services 115 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Introduction to IDP

• What Is IDP? • Why Use IDP? • How Does IDP Work with Other Products?

116 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Intelligent Device Platform

• Wind River® Intelligent Device Platform is: – a scalable, sustainable, and secure development environment that simplifies the development, integration, and deployment of gateways for the Internet of Things (IoT) – based on Wind River industry-leading operating systems, which are standards-compliant and fully tested, and includes Wind River development tools • The platform provides device security, smart connectivity, rich network options, and device management. • Intelligent Device Platform includes ready-to-use components built exclusively for developing machine-to- machine (M2M) applications.

Wind River Education Services 117 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Architecture

Manageability Runtime Environment Security

WebIF OMA-DM OSGi OpenSSL TPM Engine Lua Online TR-069 OpenJDK Secure Package Update Management

Intel Security Embedded Control Connectivity Remote Attestation Wireless Wired Protocols Encrypted Storage

Resource Control

Wind River Linux 5.0.1 Application Integrity Monitor

Board Support Packages for Intel Quark, Bay Trail Secure Boot

118 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

IDP Connectivity

Wireless Wired Protocols Mobile – 2G/3G/4G/LTE Ethernet RS-232 OPC-DA IPSec Bluetooth – Low Energy USB Host RS-485 MQTT PPTP Wi-Fi – AP/Client/AdHoc USB Device CAN Bus OpenSSL L2TP 802.15.4 ZigBee GPIO I2C SPI

Cloud Connectivity Digi

MODBUS CoAP

Cloud Connectivity Soln Family Eurotech

Wind River Education Services 119 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

What Is IDP?

• An add-on product to Wind River Linux. • Provides additional capabilities and extensions which support the creation and management of smart distributed systems. • These include smart services with cloud computing. • Secure, remote management features are included which provide automated customer interaction and support.

120 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Key Features

• Gateway security delivers built-in security features designed to secure the communication channel, the data, and the end device. • Application enablement provides Lua, Java, and OSGi application environments to enable portable, scalable, and reusable application development on both resource- constrained and full-featured devices. • Device connectivity embraces IoT protocol MQTT for data transportation and native support for Wi-Fi, Bluetooth, ZigBee, and short-range wireless protocols widely used in IoT devices. • Remote device management supports well-established management protocols such as TR-069 and OMA DM.

Wind River Education Services 121 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

What Does IDP Require?

• Wind River Linux, 5.0.1, or later • Wind River Workbench 3.3 or later is supported but not required • One of the supported processor architectures and boards

Supported processor architectures in IDP XT - intel-quark, intel-atom-baytrail Supported boards in IDP XT - Cross Hill, Clanton Hill, Advantech UTX-3115

122 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Who Would Use IDP?

• IDP supports the development, deployment and management of smart systems.

Activity/Role Also known as System Owner owner, operator, service provider, end user Device Development Vendor OEM, integrator Application Development Vendor software provider

IDP users utilize many roles. There are no hard and fast lines on how these roles are divided - this slide simply lists some of the major types of activities that most products require.

Wind River Education Services 123 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Roles

• System owner and owner roles are usually the same thing. • Device development vendor and device developer roles are members of the hardware development team. • Application developer, software provider, and application development vendor roles are members of the software development team.

124 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Who Would Use IDP? (cont’d)

Activity/Role Description interacts with applications and consumes output of End User the device the team that puts together the hardware, firmware, Integrator all software into the device Installer deployer/activator of the device in the field Service Provider typically provides the data connection to the device Software Provider a team that provides applications for the device OEM whoever builds the hardware used in the product team providing ongoing management of the device Operator after deployment specifies the functionality of the device, and manages Owner it throughout the device lifetime

Wind River Education Services 125 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Introduction to IDP

• What Is IDP? • Why Use IDP? • How Does IDP Work with Other Products?

126 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Why Use IDP?

• The world is undergoing a transformation from isolated systems to Internet-enabled devices that can network and communicate with each other and the cloud. • IDP is Wind River’s product aimed at enabling customers to quickly and easily create, program and connect these devices. • IDP is developed with an emphasis on several general uses. Each of the following is an example of the kinds of projects/products for which IDP was developed: – Smart Metering – Set Top Box

Wind River Education Services 127 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Smart Metering Example

• HydroCo, an electrical utility company, is running a smart metering project. • HardwareCo will supply the meters, which will communicate to the head office using 3G. • SWVendorCo will write the software application. • MobileCo will provide the SIM card and network connection. • CableGuys will install the meters at the end user locations. • HydroCo will manage data collection and device management.

128 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Smart Metering Example (cont’d)

• HydroCo is the owner role. • HardwareCo is OEM and Integrator roles. • SWVendorCo is the software vendor role. • MobileCo is the service provider role. • CableGuys is the installer role. • HydroCo is the role that manages the device throughout its lifetime. • Customer is the end user role.

HardwareCo HydroCo

SWVenderCo

Device

MobileCo CableGuys

Wind River Education Services 129 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Set-Top Box

• CableCo provides television, telephone, and internet services to its customers. CableCo wants to deploy a new set-top box with advanced capabilities. CableCo will specify functionalities, select hardware, and use its existing retail outlets and installation technicians. • DRMCo will provide conditional access software and smart cards for the box and the video broadcast servers. • STBCo will provide the hardware and base operating system, which they will purchase from a separate OEM. • AppCo will provide the application software and middleware.

130 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Set-Top Box (cont’d)

• CableCo is the owner, operator, service provider and installer roles. • STBCo is the OEM & integrator roles. • DRMCo is the software provider role. • AppCo is the software provider role. • Customer is the end user role.

Wind River Education Services 131 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Introduction to IDP

• What Is IDP? • Why Use IDP? • How Does IDP Work with Other Products?

132 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

How Does IDP Work With Other Products?

• IDP is an add-on product to Wind River Linux 5.0.1.7 or later. As such, is a prerequisite to use IDP. – The fourth digit is the RollingCumulativePatchLevel (RCPL) number. • Use Wind River Workbench throughout the development project to create, modify, and debug the software images used in the product. • Use a Wind River ICE2 to debug processes of the devices (especially during boot).

RCPL is important. This is how and where patches and updates are distributed from Wind River. IDP works with Wind River Linux 5.0.1.7 or later.The 7 is RCPL 7. It shows up when you conﬁgure your IDP platform project.

Wind River Education Services 133 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Documentation

• The following documents are available in HTML and PDF in your product installation – Wind River Intelligent Device Platform XT Programmer's Guide – Wind River Intelligent Device Platform XT Release Notes – Wind River Intelligent Device Platform XT Security Guide – Wind River OPC User's Guide (Wind River Linux Version) – Wind River DCOM User's Guide (Wind River Linux Version) • The following documents are available in PDF in your product installation: – McAfee Embedded Control User Guide – McAfee Application Control Product Guide – McAfee Application Control Command Line Interface Guide – McAfee Change Control Product Guide – McAfee Change Control Command Line Interface Guide

All documents are also available in HTML and PDF on the Wind River Online Support Web site at: http://www.windriver.com/support1

1http://www.windriver.com/support

134 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Questions

1. IDP is a standalone product. (True/False) 2. In which development activities does IDP have a role? 3. Name two typical application types for which IDP was developed. 4. The end user and owner of the product are the same entity. (True/False)

Answers

1. False 2. Most of them: owner, operator, device development vendor, software application vendor, integrator, OEM. 3. Set-top box, smart metering 4. Either. Depending upon the situation, the end user may have the owner role, or they may not. Often with a smart meter product, the owner of the smart meter is the provider of the product being metered, not the customer.

Wind River Education Services 135 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned: • The IDP environment • Other products that work with IDP • The roles of teams that use IDP • Prototypical situations in which IDP is used

136 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Introduction to IDP

Wind River Education Services 137 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

138 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

139 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

IDP Architecture

• Architecture • SRM Components • Device Management

140 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Objectives

By the end of this chapter you will be able to: • Understand IDP architecture • Identify where the IDP components are located within your system • Identify device management options provided by IDP

Wind River Education Services 141 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

IDP Architecture

• Architecture • SRM Components • Device Management

142 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Architecture

• The installed IDP product, not the device. • The layers, profiles and templates are installed into: – your Wind River Linux installation – under wrlinux-addons – as the wr-idp directory • To get access to these, the configure command for your project must include the option --enable-addons=wr-idp • Other options can follow to specify which features you want or do not want in this project. --with-template=feature/non_grsec

Wind River Education Services 143 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Architecture (cont’d)

• IDP leverages Wind River Linux tools and adds: – Security • McAfee Embedded Control,Verified boot (Secureboot),Tamper-proof file system ( Encrypted Storage), SRM signing tool, Grsecurity – Connectivity • 3G, Wi-Fi, Ethernet, Bluetooth, Zigbee, VPN, MQTT, Multiwan – Management Support • Webif, TR-069, OMA-DM – Application Development • OpenJDK, Lua, OMA-DM, Sqlite3, OSGi, MQTT • On top of the existing – Compilers and tools – Wind River Linux

144 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

IDP Development Environment

Software Development Environment Wind River Workbench • Eclipse framework (Galileo) 3.5 • Eclipse CDT project 6.0 • Wind River GNU compiler • User space and kernel debuggers • Linux user & kernel space configuration tools • Run-time analysis tools: • System viewer • Memory analyzer • Performance profiler • Data monitor • Code coverage analyzer Additional Tools Add-ons • OSGi Eclipse Plug-ins

Common development environment across all supported hardware

Wind River Education Services 145 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Runtime Components Base System Runtime Image Wind River Linux • Version 5.0 • UEFI EDK II • Kernel 3.4 • i586 tool chain Runtime Environments Connectivity • L2TP • Lua • MQTT • Firewall • Java • WAN • Cloud Connector • OSGi* • IPSec • OPC-DA • PPP Trusted Software Stack Management • FIPS 140-2-ready OpenSSL libraries • Web based Interface • Tamper-Proof File System • OMA-DM • Role Based Access Control • TR-069 • Integrity Measurement • Secure Updates • Remote Device Attestation • Secure Boot • Intel Security Embedded Control

146 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

IDP 3rd Party Components

Add On Partner Description Distribution OSGi mBS SmartHome SDK based on OSGi Binary

OMA-DM OneAgent OMA-DM Binary

TR-069 OneAgent TR-069 Binary 802.15.4 802.154 MAC Layer + Interface Library Binary ZigBee Native ZigBee stack Binary iDigi Cloud Connector Source

• All 3rd party components come fully licensed • Runtime licensing is included as part of the customers Runtime License purchase, there are no additional deployment costs. • Source code licensing for Add-ons may be available from the various partners.

Wind River Education Services 147 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Device View

Device Security Management

Applications

IDP systems can provide the following:

• Secure connections • Secure boot • Secure software updates • Web interfaces for device management

148 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Agenda

IDP Architecture

• Architecture • SRM Components • Device Management

Wind River Education Services 149 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Layers

• IDP is an addon to Wind River Linux • It comes as layers you include in your platform project. • The layers require the argument --enable-addon=wr-idp when configuring the platform project. • The layers contain the specific features. – You can include these individually (without the rest of the layer) --with-template=feature/xxx – More on this later.

150 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Layers

• Specific layers included with IDP for Wind River Linux: – wr-srm – wr-idp-devkit – meta-java-dl – third party related: • wr-digi-idigiconnector • wr-exegin-zigbee-ia • wr-prosyst-mbs-smarthome-sdk-ia • wr-wks-oneagent-oma-dm-ia • wr-wks-oneagent-tr069

Wind River Education Services 151 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

wr-srm

• Provides secure remote management components. • Requires: – oe-core part of Wind River Linux (must use this one!) – wr-base part of base Wind River Linux – wr-features part of base Wind River Linux – wr-kernel part of base Wind River Linux – meta-networking part of base Wind River Linux – wr-idp-devkit from wr-idp add-on layer • Recommend including these layers: – wrlcompat part of base Wind River Linux – wrlinux part of base Wind River Linux

152 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

wr-srm Features

• Default template gives you: – SRM enabled initramfs – Kernel security enhancements – Grub-ima • Trusted boot – Grsecurity – Secure file system – Secure Package Management ( Signed RPM) – Openssl-fips support for application development • All of that comes when configure contains either --with-layer=wr-srm or --enable-roofs=glibc-idp

SRM packages include: keyutils, attr, cryptsetup, imtools, libtpm-utils, openpts, spm-repo, smartpm, openssl-tpm-engine, tcgbox, tpm-tools, testsuite, trousers, ima-evm-utils, openssh, openssh- misc

Wind River Education Services 153 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

wr-srm Feature Names

• grsec_std – Grsecurity and related tools • non_grsec – Virtual feature that removes the grsec_std feature provided by default. • openssl-fips – Provides FIPS 140-2 ready OpenSSL libs for applications

154 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

wr-idp-devkit

• Provides the components of IDP. • Requires these layers: – oe-core part of base Wind River Linux – wr-base part of base Wind River Linux – wr-features part of base Wind River Linux – meta-networking part of base Wind River Linux – wr-srm part of wr-idp add-on layer

• Recommend including these layers: – wrlcompat – wrlinux

Wind River Education Services 155 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

wr-idp-devkit Features

• Default gives you: – Extra kernel files from ${LAYER_PATH_wr-idp}/wr-idp/templates/default – Wireless firmware specific to machine – Board specific features defined elsewhere… • Feature wr-idp-devkit-full will get everything available in this layer except the min_footprint feature.

156 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

wr-idp-devkit Feature Names

• firewall • openjdk -bin • graphics_qt • pppoe • ipsec_vpn • pptp_vpn • l2tp • recovery • min_footprint • upnp • mqtt • vlan • netifd • webif • online_updates • wrs_qt_demo • wwan-sierra • lua app. development

Wind River Education Services 157 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

meta-java-dl

• An incomplete layer which contains packages that are referenced by oe-core items. • Idea is to include this in your bblayers.conf file which will use this to “pre-mirror” the packages. • This allows you not to download these packages, speeding up the build. • Contains things like: – Apache – Openjdk – Jakarta

158 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

wr-idp-devkit Features

• Main IDP layer, contains most features and packages: – default • Default system configuration for each supported board – firewall • Provides Linux Firewall – graphics_qt • Add Wind River QT demo – idp_devkit_full • Convientient way to include all board-independent features at once – ipsec_vpn • Adds strongSwan Ipsec VPN implementation to the project.

Wind River Education Services 159 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

wr-idp-devkit Features (cont’d)

– l2tp • Adds L2TP VPN implementation to the project – min_footprint • Decreases the footprint of image by removing packages and kernel options. – mqtt • Provides client/server tools for the MQTT protocol – netifd • Provides a port of the Network Interface Daemon from OpenWRT – online_updates • Provides ability to update target binary RPMs from an online repository. – openjdk-bin • Provides the OpenJDK binary – pppoe • Provides the point-to-point connectivity over Ethernet

160 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

wr-idp-devkit Features (cont’d)

– pptp_vpn • Provides point-to-point tunneling protocol (pptp) for VPN connections – recovery • Provides ability to create bootable recovery media for project. – upnp • Provides Universal Plug aNd Play support to the project. – vlan • Adds 802.1Q protocol and support to the project – webif • Adds Webif, web browser based interface for configuring target services – wrs_qt_demo • Add the Wind River QT demo of QT development capability. – wwan-sierra • Adds Sierra modem management apps for MC8355 & MC7750.

Wind River Education Services 161 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

IDP Architecture and Connectivity

• Architecture • SRM Components • Device Management

162 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Device Management

• OneAgent TR-069 – Auto-configuration and dynamic service provisioning – Software/firmware image management – Status and performance monitoring – Diagnostics – --with-layer=wr-wks-oneagent-tr069 • Webif – Web browser based management of network interfaces • Ethernet, Wi-Fi, 3G – Review/alter configuration of many other target system features.

Wind River Education Services 163 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Device Management (cont’d)

• OMA-DM – DevInfo provides device information that identifies the device. – DMAcc provides the authentication. – ConnMO provides management for connectivity settings. – SCOMO manages package installation and activation.

164 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Questions

1. How do you enable the IDP software for use in your project? 2. What are the device management options available in IDP?

Answers

1. At a minimum, use –enable-addons=wr-idp. Enable speciﬁc features with something like –with-template=feature/wr-digi-idigiconnector. 2. Webif, OMA-DM, TR-069, OSGi

Wind River Education Services 165 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned: • The location of the IDP components within your system • Device management options provided by IDP

166 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

IDP Architecture

Wind River Education Services 167 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

168 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

169 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

170 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Objectives

By the end of this chapter you will be able to: • Describe the uses of public-key cryptography • Understand the use of a TPM with IDP • Identify the differences between symmetric-key and public- key encryption • Identify where SRM is used within IDP

Wind River Education Services 171 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

172 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Cryptography Overview

• Cryptography is the science of keeping things secret (confidential). This is done by the process of encryption. • Cryptography is also used to provide solutions for the following problems: – Data Integrity • The receiver of a message should be able to check whether the message was altered during transit. – Authentication • The receiver of a message should be able to verify its origin (data origin authentication). • When initiating a connection, both sides should be able to identify each other (entity authentication). – Non-Repudiation • The sender of a message should not be able to later deny he sent it.

Wind River Education Services 173 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Symmetric-key Cryptography

• Oldest method of encryption – over 2,000 years old • Used in popular protocols such as secure sockets layer (SSL) and Internet protocol security (IPsec)

Encryption Secret Key K1 Symmetric-key Encrypted Message Message to Encrypt Encryption Function

Same Decryption Key

Secret Key K1 Original Message Symmetric-key Decryption Encrypted Message Function

174 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

The Symmetric-key Algorithm Secret Key

• The secret key is a piece of data, usually a number, that must be shared between the communicating sides before they can send encrypted messages to each other. • If the secret key is known, the encryption is broken. • An attacker cannot break the encryption if he has a plain text message + an encrypted message. • Secret key size (bits): – 96 – 128 – 192 – 256

• If the secret key is discovered by a third party, the encryption is considered broken, because the encryption algorithm itself is well known (Kerckhoffs’ principle). • The symmetric-key algorithm is designed in such a way that even if you posses a plain-text message and its cipher-text equivalent, you cannot use that to discover the secret key. • The size of the secret key has a major impact on the strength of the algorithm. Today, a symmetric-key algorithm is considered strong if its secret key is at least 128-bit long.

Wind River Education Services 175 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Public-key Algorithm

Alice Bob PlainText Cipher Text Plain Text

Encrypt Decrypt

Use different keys to encrypt and decrypt the message

176 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Public-key Algorithm (cont’d)

• The algorithm has just one function that is used for encryption as well as for decryption. • The action is determined by the key input.

Encryption

Public Key Public-key Encrypted Message Message to Encrypt Algorithm

Decryption

Private Key Plain-text Message Public-key Algorithm Encrypted Message

Wind River Education Services 177 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Public-key Cryptography

• With symmetric-key encryption, only the secrecy of the key provides security. • How do you keep the key secret when you need to share it between two parties, who are on other sides of the world and sometimes do not even know each other? • The solution is called public-key cryptography. • It allows the safe and secure exchange of a secret key between two parties, without requiring a secure channel between them. • This method is usually only used to exchange the symmetric secret key, not to encrypt the entire session. This is due to the slow execution time, making it unusable when transferring large amounts of data.

178 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Public-key Cryptography (cont’d)

• The basic principle is that an entity’s key Entity’s Key is divided into two keys, public and private. Although mathematically linked, it is infeasible to compute the private key from the public key (a trap door function.) • The public key is then distributed freely, and used to encrypt messages intended for the key owner. • Once a message has been encrypted using the public key, it can not be decrypted by any means other than the matching private key. • The private key is kept secret by its owner. It is never sent to anyone. The owner uses it to decrypt messages that were encrypted using his public key.

An analogy to public-key encryption is that of a locked mailbox with a mail slot. The mail slot is exposed and accessible to the public; its location (the street address) is in essence the public key. Anyone knowing the street address can go to the door and drop a written message through the slot; however, only the person who possesses the key can open the mailbox and read the message.

Wind River Education Services 179 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Public-key Cryptography (cont’d) • File types: • .pem - public-key of a specific certificate • .key - private-key of a specific certificate • .pkcs12 .pfx .p12 - password protected container format that contains both public and private certificate pair • .csr - Certificate Signing Request • .cert .crt .cer - .pem file with a different extension • .der - same function as a .pem file, but a different format • .crl - certificate revocation list

.csr - Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. It includes some/all of the key details of the requested certificate such as subject, organization, state. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate, which itself can be in a couple of formats. .crl A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration.

180 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

RSA

• RSA is the first, and still one of the most popular public-key algorithms. It was published in 1978. • In RSA, the key is created by taking two very large prime numbers and multiplying them. The product is then used, by means of mathematic manipulations, to create the public and private keys. • The cryptographic strength of the RSA algorithm is the complexity of the factoring problem, which states that there is no efficient algorithm that can find the prime factors of a number.

RSA stands for Rivest, Shamir and Adleman, the creators of the RSA algorithm.

Wind River Education Services 181 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Signing and Validation Process

• Two steps are used in the IDP signing and validation processes: – For both processes, the first step involves calculating a unique hash value of the asset (UEFI, GRUB, configuration file, kernel, package) using the SHA-256 algorithm. – For the signing process, the second step involves creating a signature of that hash value using the RSA encryption. – For the validation, the second step involves the RSA decryption of the signature and validation by comparison with the calculated hash value. • The RSA algorithm used is RSA 2048 with the PKCS1-PSS padding scheme.

182 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Signing an Asset

• In the first stage of signing an asset, a SHA-256 hash value is calculated on the asset. • An encrypted copy of this hash value is then created using a Private Key and the RSA algorithm. This is referred to as the signature of the asset. The signature is then added to the asset

Wind River Education Services 183 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Header Structure

• During the signing process a Secure Boot Header (SBH) is created • A Secure Boot Header can be prepended to an asset or it can be kept in a separate .csbh file • The Secure Boot Header is made up of three components: – Security Header – RSA Public Key – RSA Signature

See Intel R Quark SoC X1000 Secure Boot Programmer’s Reference Manual (PRM) for detailed Secure Boot Header structure

184 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Validating an Asset Signature

• The integrity of the asset can be verified by again calculating a SHA-256 hash value of the asset. • The signature that was attached to the asset is decrypted using the Public Key associated with the key used to create the signature. • If the decrypted signature matches the calculated asset hash value, the asset is valid.

Wind River Education Services 185 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Signing/Validation Signing

Asset Hash Signature SHA-256 hash RSA 2048 encryption with private key Validation

Asset Hash If the decrypted signature SHA-256 hash matches the calculated hash value, the asset is Signature Hash valid.

RSA 2048 decryption with public key

186 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

Wind River Education Services 187 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

IDP Personas

• We use personas to ease the discussion of the various roles and jobs that are accomplished with IDP. • Often, an IDP based project will cross multiple companies, divisions, or departments. • Using personas helps us discuss a collection of responsibilities that must be accomplished, without getting bogged down with the actual entity performing them. • The personas remain the same, though for a given project the entity performing that task may be different from a previous project.

188 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

System Owner

• The system owner controls the security of the system and its devices. System images and application software is typically provided by vendors, in the form of installable packages (for example, RPMs). • The system owner serves as the authority that provides the vendors with a vendor CA certificate that lets them sign their images and packages. • The system owner can use any tool to generate their own keys and certificates for vendors.

Wind River Education Services 189 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Vendor

• Vendors sign their packages using a vendor certificate received from the system owner. • Package types include system image, file system, and application packages for secure remote management. • During development, vendors can simulate the owner role using the SRM signing yool (SST) until the actual CA certificate is available. • Before deployment, these simulated certificates must be replaced with a real signature based on the CA certificate from the system owner.

190 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

End User

• The end user validates all software before installing it on a device. • Using IDP tools, this validation is done as part of the software installation and update process. • In common scenarios, the system owner also has the role of the end user.

Wind River Education Services 191 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Remote Attestation

What is it? I need a way to prove that you are who I think you are ….

How does it work? At a high level …

2. Send Nonce in Management 1. Generate a Target the clear to the Console Random Nonce Target device. 6. Are they Random Identical? Random Nonce Nonce 3. Encrypt Nonce with Targets Private Decrypted Encrypted Encrypted Key Nonce Nonce Nonce 5. Decrypt Nonce with 4. Return the Targets Public Key Encrypted Nonce

192 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

Wind River Education Services 193 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Key Management

• Vendors sign the system image, file system, and application packages for secure remote management to prevent unauthorized changes to the device. • IDP provides the SRM signing tool (SST) to sign boot loaders, kernel binaries and RPM packages. • Device developers provide system software, including the system build. • Application developers provide software in the form of signed RPMs. • Both developers receive vendor certificates from the authority. • The vendor certificate allows the developers to sign the system image and application packages so devices can tell if the authority has approved the software for installation on the device.

194 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Security Roles

• Device Owner: Owns devices and authorizes certificates to device and software vendors, and deploys and manages devices. • Device Vendor: Builds images, signs images with a private key of an authorized certificate, and manufactures devices for the device owner. • Software Vendor: Builds applications, signs software with the private key of an authorized certificate, and supplies software to the device owner. Device Manage Certificates Owner Device Apply Manage Software Device Certificate Device Authorize Authorize Certificate Certificate Apply Device Certificate Software Vendor Vendor

Wind River Education Services 195 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

SRM Signing Tool

• It is used to: – create keys for the different roles – sign GRUB images and inject root certificates – sign the Linux kernel – sign all components (GRUB stage2, Linux kernel, applications) in a rootfs tar ball – sign RPM packages and applications within the packages

Vendor Owner Key Pair Certificate Unsigned Software Signed Software GRUB Stage 2 GRUB Stage 2

Linux Kernel Linux Kernel

Rootfs Tar Ball SST Rootfs Tar Ball

RPM Package RPM Package

196 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

SST

• Vendors use SST to sign their packages (kernel image, RPM, etc.). • SST can run on a development host or on any Linux server without IDP installed. • SST lets vendors simulate the owner role during the development stage, before they receive owner certificates. • SST currently supports intel_atom and intel_quark devices. • NOTE: Before final production, you must obtain keys and certificates directly from the owner and install them on the device. This is the only way to protect the deployed device from loading unauthorized software. SST can use the keys provided by the system owner.

• You must have root privileges to use the sign-all subcommand.

• The target boots if the boot loader is not signed. However, if the boot loader is signed by an incorrect SST owner certiﬁcate, the system does not boot.

• The target does not boot if the boot loader is signed but the kernel is not signed correctly by SST.

• The target does boot if neither the boot loader nor the kernel image is signed.

• The validity period of certificate produced by SST is ten years, starting at the local time on the producing machine that created the certificate. The certificate time must be consistent with the time on the target.

Wind River Education Services 197 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

198 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Trusted Platform Module

• The trusted platform module (TPM) is the root of the chain- of-trust used within IDP. • The TPM offers facilities for the secure generation of cryptographic keys, and limits their use. It also includes capabilities such as remote attestation and sealed storage. • Software can use a TPM to authenticate hardware devices. Since each TPM chip has a unique and secret RSA key burned in as it is produced, it is can perform platform authentication.

Wind River Education Services 199 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Trusted Platform Module

• Endorsement key = RSA key pair

Figure created by Guillaume Piolle, GPL 2.1 license

200 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Trusted Computing Group

• Industry group that created the specifications for TPM. • Trusted computing is the name given to devices that use TPM. With trusted computing, the computer consistently behaves in expected ways, and those behaviors are enforced by computer hardware and software. • Enforcing this behavior is achieved by loading the hardware with a unique encryption key that is only readable by the rest of the system. • Booting the system is one of the behaviors that this mechanism can enforce.

Wind River Education Services 201 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

TCG Components in IDP

• GRUB-IMA – an enhanced version of the standard GRUB boot loader that supports TCG-compliant computers equipped with TPMs • TrouSerS – open source trusted computing group software stack (TSS) – tcsd daemon is a user space daemon that must be the only portal to the TPM device driver. • OpenPTS – A proof-of-concept (PoC) and reference implementation of platform trust services (PTS) from TCG – used for device attestation (proof that software has not changed)

202 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

TPM

• You can use TPM and associated tools to generate keys and store RSA key pairs. • You can also protect your private key by storing it in TPM hardware and by performing on-chip encryption and decryption. • When you generate a key with the TPM hardware, the TPM chip itself stores the private part of the key (rather than in a private (permission protected) directory on your machine). • The TPM chip must do all the encryption and decryption steps that require the private key. • Even if you generate the private key on a host machine using OpenSSL tools, you can still use the TPM engine to protect the private key. • The key wrapping feature of TPM wraps the private key so that only TPM can parse and use it.

Wind River Education Services 203 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Secure Remote Management Basics

• Public-key Cryptography • IDP Personas • Key Management • Trusted Software Stack • SRM Features Using TPM

204 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

OpenSSL TPM Engine

Why use a TPM? Apps . Protect private keys deployed

OpenSSL Library on device from leaking

TPM Engine Other benefits:

TSS . Shares same APIs as OpenSSL libc/libz (TrouSerS) . Securely generate, store and Linux Kernel use RSA key pairs (TPM Driver, IMA) . Wrap software keys into TPM

TPM storage

Wind River Education Services 205 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

SRM Features Using TPM

• Verified Boot — IDP XT offers Verified Boot for Cross Hill, Clanton Hill, and Advantech UTX-3115 boards using software verified boot. • Device Attestation — The secure remote management feature of IDP is designed to prevent a man-in-the-middle attack when communicating remotely with an IDP target. • Encrypted Storage Device — Provides secure storage for application data on Intel Architecture devices. • Key Generation (with OpenSSL TPM engine integration) — You must include the openssl-tpm-engine package in your platform project to use the TPM for this.

Ecrypted storage uses the package dm-crypt.

206 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Questions

1. What is SST and why would you use it? 2. What does TPM mean and why would you use it? 3. How are keys used in IDP? 4. What is the primary difference between symmetric-key and public-key encryption? 5. TPM is only available with Intel Architecture hardware (True/False)

Answers

1. It is the SRM signing tool. You use it to sign your RPMs and boot images for use with IDP. 2. Trusted platform module. TPM is hardware you use to generate and store keys used to sign your original software and to validate new software. It is also used to generate new keys, and to attest that the running software matches what is expected (device attestation). 3. To sign system images (kernel, ﬁle system, new RPMs), and to prevent unauthorized access to the device and unauthorized software from being installed. 4. Symmetric-key encryption uses a single key, while public-key encryption uses two keys (a public and a private key). 5. False. IDP only supports Intel BSPs, but TPM is available from many manufacturers.

Wind River Education Services 207 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned to: • Describe the uses of public-key cryptography • Understand the use of a TPM with IDP • Identify the differences between symmetric-key and public- key encryption • Identify where SRM is used within IDP

208 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Secure Remote Management Basics

Wind River Education Services 209 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

210 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Verified and Secure Boot

211 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

212 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Objectives

By the end of this chapter you will be able to understand: • Secure boot workflow • Hardware components involved with the secure boot • UEFI security enhanced GRUB boot loader grub-efi • Verified boot workflow • SRM Signing Tool (SST)

Wind River Education Services 213 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

214 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Overview (1/3) 1. Upon reset, using it’s protected internal Boot ROM, the CPU verifies and starts UEFI. 2. UEFI loads and verifies grub-efi (UEFI security enhanced GRUB), extends measurements to TPM if present 3. grub-efi loads and verifies the Linux kernel, extends measurements to TPM if present.

Secure Boot Chain of Trust

Extend TPM Root of Measurements Trust

CPU 1 UEFI 2 grub-efi 3 Linux Kernel

Load & Load & Load & Verify Verify Verify

Wind River Education Services 215 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Overview (2/3)

• Only authenticated software that has been cryptographically verified can be run on a IDP system. • The concept is based on a root-of-trust (RoT) from the reset vector, through to the run-time kernel. • Each phase of the boot verifies the next phase of the boot, before handing off to that phase.

216 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Overview (3/3)

• The signed grub-efi is loaded from the SPI flash. The grub.efi.csbh signature file of grub.efi, is also located in the SPI flash. • UEFI verify if the grub-efi matches with the grub-efi.csbh. If verification passed, then UEFI starts grub-efi. • grub-efi loads and verifies grub.conf and Linux kernel

Wind River Education Services 217 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure vs Verified Boot • Secure Boot – Target includes Secure Boot ROM or Trusted Platform Module (TPM) which serve as hardware based root of trust – Security checks are carried out before launching the UEFI firmware, boot loader, OS and software stacks • Verified Boot – No hardware based root of trust is available – The root cert of Integrity Measurement Architecture (IMA) is embedded into the grub-efi – Secure features like tamper proof file system and secure package management are still available

218 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Workflow

UEFI from SPI flash UEFI verifies grub.efi

Wind River Education Services 219 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Start

• Intel® Quark implements a root of trust that starts executing code from ROM at the reset vector (0xFFFFFFF0). • This ROM code authenticates the UEFI firmware before passing control to it. • The ROM code will not launch UEFI firmware if it fails authentication. • UEFI firmware is split into two firmware volumes: – Stage 0 Firmware Volume – Stage 1 Firmware Volume

220 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Stage 0

• The Hardware Root of Trust (HW RoT) on Intel® Quark is made up of two components: – The software executed from the on-die ROM. – The public half of the first RSA key (stored on-die) used in the Boot flow validation process. • The on-die key, referred to as the Device Key, is programmed by the factory at Intel. • Secure Boot code executing in Stage 0 is broken into two stages: 1. The authentication of an RSA Public key stored in SPI Flash. 2. The use of this key to then validate the Stage 1 application.

Wind River Education Services 221 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Stage 0 Workflow

• Stage 0 overview: – Out of reset, embedded SRAM is configured. – An Isolated Memory Region is configured to protect the eSRAM – The Key Module is copied to eSRAM, authenticated and the Stage 1 Public Key is extracted. – A check is done to see if a Master Flash Header exists. – The Master Flash Header is searched for the first Signed Stage 1 application. – The Signed Stage 1 application is copied to eSRAM. – Stage 1 application is authenticated. – If authentication is successful, execution is passed to that application and Stage 0 is complete.

See Intel R Quark SoC X1000 Secure Boot Programmer’s Reference Manual (PRM) for complete Stage 0 overview, including negative scenarious

222 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Stage 1

• Stage 0 software operates from on-die ROM. • It must know how to find the Signed Stage 1 Public Key and Signed Stage 1 Application in order to authenticate and launch a Stage 1 Application. • The Stage 1 Public Key is stored the Key Module and is stored at a fixed location in the SPI flash. • It is possible to have multiple Stage 1 applications (for redundancy and fault recovery), all of which stored in the SPI flash.

Wind River Education Services 223 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Key Module

• The Key Module contains a signed copy of the public half of the Stage 1 Key which is used during the authentication of Stage 1 applications. • The location of the Key Module in SPI flash is fixed by the Stage 0 code implementation.

224 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Isolated Memory Regions (IMRs)

• Quark SoC has implemented IMRs to help protect memory during system operation. • Software can configure IMRs to allow/deny access by certain system agents to programmed memory ranges. • UEFI firmware restrict memory access to various regions only to the system agents that must have access. • UEFI firmware lock any memory regions that must persist through OS boot and beyond.

Wind River Education Services 225 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

OS Security

• IMR protection is added to the uncompressed kernel – IMR is placed around executable sections of the kernel image. – IMRs that are not required for the run-time system are tear down. – Unlocked IMRs are locked. – Debug interface to view the size, extent, and state of each IMR is provided.

226 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

Wind River Education Services 227 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Boot loader Security

• Second stage boot loader executes: – Asset verification • Kernel • Boot loader config file - grub.conf • Init RAM disk – IMR setup/teardown • IMR setup for kernel boot parameters • IMR setup for compressed kernel image • A chain of trust exists through boot loader into kernel • All assets executed have been validated and encapsulated within an IMR.

228 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Grub-efi - Asset Verification Flow

• Grub-efi verifies any kernel, init RAM disk or grub-efi configuration file it relies upon in secure boot mode. • Grub-efi executes the boot logic given to it in grub.conf. • The grub.conf file specifies which boot assets are signed and which are not. • The grub.conf file also specifies where to find boot assets. Supported locations are: – SPI Flash – SD/USB mass storage device

Wind River Education Services 229 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Grub-efi - Asset Verification Flow • In secure boot mode, grub-efi will: – Parse the master flash header to identify the location of grub.conf – Read in the contents of grub.conf – Verify grub.conf against a cryptographic signature • For each item marked as secure in the grub.conf file – Search for an asset signature – Verify the asset against the asset signature • Grub-efi will execute UEFI recovery in case of: – failure to find an asset or an asset signature – failure to verify an asset against an asset signature

230 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Grub-efi - Isolated Memory Region Flow

• Grub-efi is booted by UEFI with IMRs already configured around a number of assets • Grub-efi will read a Linux kernel image from SPI flash or from USB/MMC mass storage. • IMRs are configured as: – IMR1 used to protect kernel boot parameters structure – IMR7 used to protect the compressed bzImage in memory • Grub-efi verifies bzImage against the cryptographic key when the compressed image is placed within the IMR protection region. • Then control is handed from grub-efi to the compressed kernel image with IMRs active for IMR1 and IMR7

Wind River Education Services 231 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Grub-efi Configuration File Location • Grub.efi will try to load grub.conf from: – external storage like USB storage first, – then from SPI flash if not found in external storage – the recovery grub.conf and its matching grub.conf.csbh are also present in the flash image. • Grub.efi will try to find: – the first partition of the first storage device, (hd0,0) device in grub-efi. – /boot/grub/grub.conf and /boot/grub/grub.conf.csbh on the first partition

232 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Grub-efi Configuration File Location • If the grub.conf.csbh does not match with grub.conf, – grub.efi will drop into ‘recovery shell’ • You can not edit boot menu at runtime as this is considered a security vulnerability. • If the verification of grub.conf success, then the grub.efi will show boot menu based on content of grub.conf (see following slides).

Wind River Education Services 233 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Grub-efi Menu

• USB, MMC - boot media listed • secured SKU - secure boot; for verified boot you would see “secure boot disabled” output • grub from SPI - grub-efi from the SPI flash is used • grub cfg from spi - grub.conf file from the SPI flash is used; If you see “grub cfg from storage” - grub.conf file from the boot media is used;

234 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Boot Failures (1/2)

• Kernel failed on verification, no signature file

Wind River Education Services 235 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Secure Boot Failures (2/2) • Kernel failed on verification, corrupted signature file

• Kernel failed on verification, wrong/mismatch signature file

236 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

Wind River Education Services 237 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

SPI Flash Organization

• SPI-layout-tool - generates Flash image in two formats: – .bin flash image the could be used to burn into flash – .cap file to enable CapsuleUpdate

238 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

8 MB SPI Flash Layout

See Intel R Quark SoC X1000 Secure Boot Programmer’s Reference Manual (PRM) for more information on SPI Flash Layout

Wind River Education Services 239 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

SPI Flash Firmware Update

• During the IDP platform project build .bin and .cap files are created for different supported board types • .bin file – Use SPI flash programmer to program .bin file • .cap file – From UEFI shell - use CapsuleApp.efi UEFI command – From Linux shell # cp .cap /lib/firmware # echo -n .cap > /sys/firmware/efi_capsule/capsule_path # echo 1 > /sys/firmware/efi_capsule/capsule_update # reboot

SPI - Serial Peripheral Interface

240 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Redundant Images

• Corrupted SPI flash images or images that fail to authenticate should not leave the system un-recoverable. • UEFI firmware achieves this by providing redundant Stage1 Firmware Volumes: – Boot Stage1 Firmware Volume Image1 - This is the first Stage1 Firmware Volume – Boot Stage1 Firmware Volume Image2 - This is the redundant Stage1 Firmware Volume – Fixed Recovery Firmware Volume Image - This is the fixed Recovery Firmware Volume

Wind River Education Services 241 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Redundant Images

• To reduce the risk of ending up with all Firmware Volumes corrupt, it is recommended that all Firmware Volumes should not be updated in the one update. • Fixed Recovery Firmware Volume will be updated rarely. – The Fixed Recovery Firmware volume just needs to be ’good enough’ to recover the system. – Updates to it are only expected to address security vulnerabilities.

242 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Secure Version Number (SVN)

• The SVN Array is stored at a fixed location in the SPI flash, at physical address FFFD0000h. • This allows for a maximum of 32 KB of storage space up to the next fixed location in the memory map which is the Key Module. • SVN stored at the relevant offset in the SVN Array is validated with the SVN stored in the Secure Boot Header of the asset being authenticated. – If both SVN match or the SVN attached to the asset is higher than that in the array, the asset validation is successful. – If the SVN from the SVN array is lower than the asset SVN, validation has failed.

Wind River Education Services 243 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

UEFI Boot Secure Lock Down

• UEFI firmware only supports booting an image (OS boot loader/ UEFI application) from a known location in legacy SPI flash. • This removes the risk of unknown UEFI applications/drivers being loaded from USB/SD/UEFI shell. • For secured embedded systems, it is expected that the system will always boot from a known image at a known location. • UEFI Boot manager is capable of booting images from other media (USB/SD/UEFI shell), but Intel® Quark UEFI firmware restricts the boot manager from booting these images.

244 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

Wind River Education Services 245 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Verified Boot

• The root cert of IMA is embedded into the grub-efi • Grub-efi is signed by signing tool at build time and then verified at runtime. • The signing tool is provided by Intel. To use Intel provided key module to sign software components/blobs. The signing process generates signatures for software components. • Singing tool also need ‘Rom Key’ as the key, also provided by Intel.

$ sign -i grub-idp.efi -o grub-idp.efi.csbh \ -k keys/quark-romkey/key.pem -b 0x400 -s 0 -x 6 -c

$ sign Sign an asset for secure boot Usage: ./sign [OPTION]. . . -i -o -b -s -x -k -c create csbh ﬁle -l disable output ﬁle size limit (1GB)

246 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Verified Boot

• The root-of-trust begins from grub-efi stage 2. • Stage 2 of the loader calculates a checksum for the Linux kernel and verifies it against the signature attached to the kernel. • If the verification fails, do not load kernel and do not boot. • Check the public keys and only allow signed software to run on the device.

Wind River Education Services 247 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Agenda

Verified and Secure Boot

• Secure Boot • GRUB Boot loader • SPI Flash • Verified Boot • SRM Signing Tool

248 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

SRM Signing Tool (SST) It can be used to: . Sign Grub-efi images and inject root certificates . Sign the Linux kernel . Sign all components (Grub-efi stage 2, Linux kernel, applications) in a rootfs tar ball . Sign RPM packages and applications within the packages

Unsigned Software Signed Software

grub-efi stage 2 grub-efi stage 2

Linux Kernel SST Linux Kernel Rootfs tar ball Rootfs tar ball

RPM Package RPM Package

Vendor Certificate Owner Certificate

Wind River Education Services 249 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

SST grub.efi Signing # SST sign-bootloader --machine=intel_quark \ --ownercert=keys/owner-cert.pem --romkey-dir=keys/quark-romkey \ grub-idp.efi

250 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

SST Certificate Deployment 1. Before deploying an image, SST

File System inserts the root certificate for IMA Deploy Appraise into grub-efi (using the Userspace 5 App Authorized sign-bootloader sub-command). Certificate Utilize 2. At boot time, grub-efi passes the Access 4 5 Utilize root certificate to the Linux kernel Root Certificate 3 3. The Root certificate can’t be Linux Kernel changed after device boot up Pass 2 4. Apps requests access to the root Root Certificate Grub-efi certificate via the Kernel 5. When deploying a new certificate 1 to the target or to utilize an SST existing certificate, the certificate must be verified to ensure that it’s authorized by the root certificate

Wind River Education Services 251 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Wind River Linux 5.x and Intel Gateway Solutions for IoT

Review

In this chapter you learned about: • Secure boot workflow • Hardware components involved with the secure boot • UEFI security enhanced GRUB boot loader grub-efi • Verified boot workflow • SRM Signing Tool (SST)

252 Wind River Education Services Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

Veriﬁed and Secure Boot

Wind River Education Services 253 Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute Subject to Wind River Terms of Use - Do Not Copy – Do Not Distribute

http://education.windriver.com [email protected]