Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

BUD17-313: BoF - Device Tree and Secure Firmware

2 789 vues

Publié le

"Session ID: BUD17-313
Session Name: BoF - Device Tree and Secure Firmware - BUD17-313
Speaker: Joakim Bech, Jens Wiklander
Track: Security

★ Session Summary ★
Device Tree is well established in the Linux kernel. But since there could be other bootloader(s) and firmware components involved that needs to configure the hardware and thereby also needs to update the Device Tree blobs before passing it to Linux kernel. Therefore we are looking for a well established way for firmware to also make use and modify the Device Tree blobs before handing them over to Linux kernel. With this BoF session we would like to get started a gather ideas etc.
★ Resources ★
Event Page: http://connect.linaro.org/resource/bud17/bud17-313/
Presentation: https://www.slideshare.net/linaroorg/bud17313-bof-device-tree-and-secure-firmware
Video: https://youtu.be/kbREjQS3moM

★ Event Details ★
Linaro Connect Budapest 2017 (BUD17)
6-10 March 2017
Corinthia Hotel, Budapest,
Erzsébet krt. 43-49,
1073 Hungary

Keyword: BoF, security, firmware
Follow us on Social Media

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

BUD17-313: BoF - Device Tree and Secure Firmware

  1. 1. BUD17-313: BoF - Device Tree and Secure Firmware Joakim Bech and Jens Wiklander
  2. 2. ENGINEERS AND DEVICES WORKING TOGETHER Device Tree recap ● It’s used to describe hardware capabilities ● It’s a tree where the capabilities are described in nodes and properties ● It’s a separate binary (DTB), which is passed to Linux during boot ● Until now(?), it has mainly been used by Linux kernel
  3. 3. ENGINEERS AND DEVICES WORKING TOGETHER Device Tree in Firmware? ● Firmware is more flexible today compared to the past ● Just as kernel, desirable to have standalone binary images ● Several firmware components in use on a normal setup ○ TEE (OP-TEE etc) ○ Secure Monitor (ARM-TF etc) ○ UEFI ○ U-Boot ○ Grub ● There are uses cases when firmware wants to use and eventually modify things before handing over to kernel ○ Reserve (secure) memory ○ Secure peripherals ○ Update available memory based on SoC specific probing ○ Supply boot arguments for the kernel
  4. 4. ENGINEERS AND DEVICES WORKING TOGETHER Are DTB’s used in firmware today? ● U-Boot / UEFI ○ Updates available memory based on SoC specific probing ○ Updates the /chosen node ● OP-TEE ○ Adds /firmware/optee node in the DTB ○ Adds /reserved-memory/optee@0x12345678 node if needed ○ Updates passed DTB in place ● ARM-TF ○ Used by “plat-QEMU-virt” ○ Creates “/psci” nodes and assigns the “enable-method” ○ Passes the DTB to OP-TEE and UEFI ARM-TF OP-TEE UEFI / (U-Boot) Linux kernel
  5. 5. ENGINEERS AND DEVICES WORKING TOGETHER What’s next? Ideas, questions, issues? ● The proposals we have are ○ Apply the “QEMU” pattern on true hardware ● Where to modify DT? ○ DTS in kernel only? DTS copied to firmware and modified? In memory modifications only? ○ /proc/device-tree might look different compared to the dts-file. Tagging only a better idea? (see Peter Maydell’s devicetree/bindings/arm/secure.txt in kernel). ● What else do we need to think of? ○ Overkill to use libfdt in firmware? (ARM-TF#454) ○ Where are the bindings docs maintained? ○ FOTA updates, how to handle the DTB in firmware? ○ Read from flash once? Who? ARM-TF? ○ Splitting a DTB into several DTB’s?
  6. 6. Thank You #BUD17 For further information: www.linaro.org BUD17 keynotes and videos on: connect.linaro.org joakim.bech@linaro.org - jens.wiklander@linaro.org