Boot, Init & Config Microconference Notes - Ravenna
How do we get to "Very Small Kernels" securely booting rapidly?
SCHEDULE
Securing the Entire Boot Chain - Matthew Garrett
UEFI Secure Boot:
- implementation of wider class of technologies that are verified by an ecrypted path.
- Working to ensure not modified, and preserve trust.
- - Currently use "shim" with physical presnence guarantees.
- - each stage verifies next stage before transfering control to it.
- - no way to verify pops up the dialog box.... concern point.
- - most distributions (except Ubuntu) follow this.
- - rooted in the firmware - and trust supporting first hvalidation correctly.
- - but.... there are risks here.
Verified boot.
- - verifies prior step.
- - hardware may modify the firmware actually running. We'll define hardware as out of scope.
What can we do about these issues?
- - Firmware is not trustworthy, etc.
Considered Measured Boot
- - just records what occurs.
- - Small cryptographic device (TPM implemented in software on trusted part of the stack, ex. trustzone on ARM, tpm on intel.)
- Q: on arm who starts execution first?
- In TPM setup, signed and verified by SoC itself, one of the first things. Problem is other code in trustzone could interfere.
- -TPM is VERY slow (8051 type microcontrollers at 200MHz) - for signing, encrypting symmetric keys, do actual decryption on actual CPU.
- - able to store a measurement of the boot process. PCRs are 20 byte registers, capable of storing a SHA1 hash. Only way to get
- value in PCR is to do same writes, or break SHA1. TPM 2.0 uses SHA256. Also Russian or Chinese equivalents.
Can combined verified boot and measured boot.
- - Intel Boot Guard - able to hash into TPM.
- - trusted grub, patches applied to grub 0.97. Any writers of trusted grub?
- <add Matthew's URL> for pointer to github source.
- - get and build and do measurement.s
Static Root of Trust
- - must do exactly the same thing. Do different measurements during boot)
Dyanic Root of Trust
- - TXT trusted execution (intel specific feature) on boundary transitions, look at resources. Flip to truseted code.
- - it doesn't matter how you got to a point, measure system state at a point in time. System state should be identical as should measurements.
TPM is not able of enforcing outside the TPM, stopping the boot process.
Needs a mechanism for communicating its methods. Create a signed copy of the PCR values - called quote.
Not useful to local user, as no means of communicating other than OS. OS may be untrustworthy - intercept of values, etc.
Attestation:
- when encrypt data with TPM, example: encrypt hard driver encryption key.
- downside, booting without pass-phrase.
TOTP
- consider two factor authentication and then uses TPM to encrypt it.
- asked TPM to decrypt.
- locally demonstrate you're running the code is trusted state.
Remote Attestation:
- chain of trust through key used to sign PCRs and endorsement key set by manufacturer.
- attestation to separate physical device. Desktop/laptop to phone. Enterprise world?
Q: How might work in embedded space/IotT?
All IoT devices attest to hub in trusted state.
detect non trusted deivces.
Still focusted on early boot - what next?
- extend our trust beyond the firmware.
- what idea of an operating system is worth thinking about.
dm-verity file system (read only, but block device is r/w)
- additional hash tree.
- verify each block on device
- doesn't work well for packaged based distributions.
- used in chromeOS. Trust everything on file system.
- runtime able to verified images are signed, all applications in container are vefied.
- OS boot into model is trustworthy.
- No existing linux distributions do this, may be able to get away with this in embedded space.
IMA - Integrity management architecture.
- extend PCRs based on file write. Past list of measurements performed to remote site to replay and verify hashes match.
- depends on policy selections
- Practical considersations;
- phython - data or code. data should be ignored.
- if root is executing, measurement different policy violated. No way to do this for all users.
- perform verification and validation - signature per file. Distribution sign binaries - RPM and DPKG - with IMA extended attributes applied.
(ref to Finn's talk on Monday)
- distributions aren't interested so far.... but exists and could be taken advantage of in different ways.
If you're trying to sell it to distributions to support this? Which use cases?
- As a user - if someone able to modify my falls, not good. Consider "tripwire" - scan and verify still same hash. Updating tripwire db.
- Can we sell this as a solution to Docker security problem?
Can we use attestation technology for running mimages? Monitoring of virtual machines. Interjection into running image.
- Is the image started with legitamate and cryptographical verified. Boot.
- If someone interfere with image at runtime, runtime introspection of VMs is research area.
- read executable chunks, function pointers attack verctor though.... active research - lots of PhD topics here.
Atmel has ARM based SoC - claims user space binary, and they'll do the decryption between memory and the chip.
Intel are launching this in skylink - called SGX. Allocate memory at startup time, ecrypted in normal RAM.
In the cloud case, for SGX get attestation back for enclave. Don't think it will rehash stuff... Enterprise ready clouds come back.
SGX allows Deploy trusted code on untrusted hypervisors.... which is intriguing but potentially terrifying.
Use case - video codecs & hollywood IP sides.
SGX v2 - more memory allocated at runtime.
Both in agreement neeed to use hardware to help you. When cloud providers setup, TPM information could be mocked up. SGX allows gain trust in specific matters. Local deployement
PXE: Sucks: Curt Brune
Instal Environment - trying to understand what here for Server OSes.
- 3 - 4 years ago - systems came with O/S and that's it. Aiming to be closer to server world.
- install environment for embedded systems. PXE's good, but.... network operators not happy with.
- loading dock to rack experience, more modern technologies apply to this?
- subproject of Open Compute Platform.
- just instaling was historically painful due to platform dependent pieces.
- owned by hardware vendor, responsible to ensure its on the box. Level playing field for multiple OSes.
- hardware vendors forcus on just one, so win for them.
- leverages linux kernel and BusyBox.
Technical Deep Dive
- started with PPC, open question is to how put it on servers.
- on x86 network servers. ARM32, PPC so far.
- PXE like image management. Shell scripting to tie it together.
<insert link to slides, connection via PCI3 to Switching ASICs>
Boot Loader -> ONIE --> fetches -> Installer (OS Vendor) --> Netowrk OS (OS Vendor supplied)
OS isntaller runs in context of image process... 4-10MB initramfs, runs out of ram disk.
On subsequent boots, ONIE not invoked. Network OS installer.
Thinking about how this can be secured?
Yes, but not hard enough? Who needs security in switch.
Installer, user spaced program? uses URL of image. What is run time environment? User Space.
Helps with uninstall and reinstall.
How does thie compare to PetiteBoot in Power8, Petite boot is frontend for kexec
Network OS Installer Discovery and Install Behaviour
- see slides.
- lot of customers don't like serial console, but prefer to interact over ssh.
- permit script being handed back - talking to inventory control database, from meta information.
Embedded networking space.
Thinking about can drop toybox in for busybox?
- if want to build so boot under QEMU and set up ONIE test environment? Do you have this already?
- see: github/opencompute/onie repot. Documentation moved to WIKI part of github.
- there is a kvm implementation (platform independent piece). Tied to particular hardware. (ACPI for Switches: APD)
In factory uses PXE to install ONIE.
PXE with EFI - pulling down from http, tcp support broken last december.
Booting from EFI servers - ONIE worth looking at.
Thought about modifying U-Boot, but decide to just use linux.
ONIE demo
- ONIE update process same as factory install process.
Research topics in fastboot - John Mehaffy
Working on fastboot toolkit for mentor graphics, looking for help with advancing it, as changing employeers.
- deferred Initcalls
(elinux out of tree, been there for a while)
submitted by 2008, updated.
current state configured by editing sources, triggered by read
proposal: discuseed 4th state in Kconfig (D) - like Y, but defere initcall (for networking useful)
discussed having new trigger
how not interfer with fastpath?
Rather than D, maybe a flag in driver saying this is ok to run late? Then rely on Kconfig ordering.
Ordering policy? userspace saying its ok to run the deferred init calls. Doing it with EBPF filter at runtime, policy.
How are you supplying it?
==> post to embedded mailing list. Futher discussion there.
Bigger problem is how order all init calls.
- u-boot/kernel driver sharing
- some subsystems need to be ready very early (CAN bus 50ms max implies start in u-boot)
- how transfer control to kernle when ready to take over?
- - use EARLY_SERIAL mechanism (start kernel)
- - how deal with DMA? don't.
- - u-boot and kernel page tables different, multiple cpu's problem. Don't clash.
- - possibly represent with a generation counter.
Parallelism in kernel bringup.
- U-boot should provid a standard for overlapping decompression with kernel laod DMA.
- Rootfs should be mounted as early as possible
- advocating should be part of U-boot.
- if not using DMA? EMMC reading?
- rootfs being mounted as early as possible - very long. Can profitablly be started earlier in boot process.
- would help all systems not just embedded ones.
On PPC: ePAPR defines some of these for virtreg, not sure about ARM.
Need to define a document? For ARM, needs to be defined. Could be done in a completely arch independent way.
Reducing the ARM Linux kernel size without losing your mind
(see slides from Nico) - very self explanatory.
Results: the approach relying on gas modifications (now upstream) is yeilding results in the same ballpark as LTO
without the significant compliation time needed per kernel build.
Solution for the missing-forward-reference proposed (.tug ).
After this, focus will be on reducing the "peg point symbols" automatically. (configurable system calls (syscalls as modules), selective EXPORT symbols)
TWO MINUTE SUMMARY AT WRAPUP: to be provided by John Mehaffy.
Number of attendees: approx. 60 - good Q&A dynamic