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_KGrFjHftZLmTY0-23A/edit#slide=id.g7ddd37b719_1_67 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
