Attendees

François-Frédéric Ozog (Linaro) Frank Rowand Simon Glass (Google) Ilias Apalodimas (Linaro) Atish Patra (Western Digital) Mark Brown (Arm) Heinrich Schuchardt CVS Arnd Bergmann Rob Herring (Arm) Loic Pallardy (ST) Poonam (NXP) Ruchika Loic Pallardy (ST) Don Harbin(linaro)

Presentation

SLIDE 2

Francois: if we want authentication, we can’t do fix up

Simon: what is fix up? Can’t change DT or ok to change it?

Francois: can orchestrate transition, [edit as typing notes: changing is not OK because you can’t identify the scope of change; adding a new node may be acceptable - because scope is easy to frame]

Simon: code doing the fixup is signed , so it may be a signal that the changes are OK; don’t know how to pass that to Linux. In principle you should rely on signed code to make changes

Francois: [rephrasing at note editing] two trust models

1) implicit - trust because generating/updating code is signed

2) explicit - trust because you can check signature of the DT

Heinrich: if the DT comes from file system, it should be signed; for DT embedded in signed code: no need to have a signature; signature for things from file but not from memory [at writing notes, I understand this as a DT fragment generated by FT-A in memory does not need to be signed]

SLIDE 3

Francois: cold-plug by U-Boot, hotplug by OS

Francois: Board DTB + cape DTBo + cape_on_board DTBo (pin muxing config, irq config…)

Frank: Device removal triggers DT correspond node(s) removal? If so, then we should limiting a single device per overlay

Francois: yes. It is also connected to device assignment. There should be a way to identify all nodes of a device in DT to actually simplify device assignment (to be discussed later in the deck)

SLIDE 4

Lets use a special config DTBo (chosen…)

Let’s get the parameters out of DT in local OS config (or worst case, in that config DTBo)

Rob: problem with systems with loadable modules

Arnd: can be passed on command line

Rob: Greg KH say: don’t add module parameters

Arnd: device specific parameters should be done via sysfs/ioctl; driver wide parameters could be as module parameters or boot command line

Frank or it could be a “chosen”

[editig time] Francois: for Linux, can we organize module parameters in modules.d are parsed when modules are statically linked?

Let’s not use DT when we can avoid (OP-TEE bus to discover TAs)

SLIDE 5

Francois: wherever we choose, we shall ensure backward compatibility

SLIDE 6

DTB=base board + 1 DTBo per device

Statically merge DTB + DTBos at compile time and keep metadata about the merge in a section of the new DT file format.

SLIDE 7

Arnd/Simon: Right now the Android boot loader merges DTB/DTBos and passes one DTB to the kernel

Simon: ChromeOS has a FIT image with multiple DTs, it selects one to pass to OS

Arnd/Ilias: FIT is only understood by U-Boot

Francois: wherever we choose, we shall ensure backward compatibility

Arnd: It’s simpler to have a single DTB for the kernel

Early kernel is not really powerful

There are security advantages in signed DTBos

Francois: I think the key question is decide on a model. Allow bootloaders to change the DTB and rely on signed DTBos?

Simon: is either or ? [explicit vs implicit trust models], what is the threat model?

Francois: yes, I think so.

Heinrich: problem is wrong voltage in DT results in destroying the board

Arnd: steal sensitive data

Ilias: DoS can become a problem

Ilias: signing per device (key mgmt complexity) ? or per device model (can compromise all devices of a model)?

Francois: Who signs what is also a fundamental concept, because there might be different signing authorities

Loic: That’s the current case wit ST devices

Arnd: There’s 3 options here:

Kernel with embedded DTB, if the kernel signature is checked, the DTB does not need to be checked

The bootloader loads the kernel from a disk

Nothing is checked

Checking one of those makes no sense

Simon: we have to be careful in not tying ourselves in a knot. There is *no* bidirectional root of trust. The model is that trust is built starting from the root of trust, the next level implicitly trusts the level that loaded it.

Mark Brown: DT is used with EDK2

Loic: there is no direct boot from U-Boot to kernel, it is vouched by OP-TEE.

security of co-processors requires the same model

Hardware firewall (device and memory) can be leveraged to ensure full security

DTE Project information portal:

https://collaborate.linaro.org/display/DTE/DTE+Progress+Updates

Security presentation: (listed in the portal, but copied here for simple access):

https://docs.google.com/presentation/d/1CvKBBZ33ggzyhP2ub8iZ410I_KGrFjHftZLm...