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...