On Thu, 3 Nov 2016 10:28:22 +0000 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On 11/3/16, mike.valk@gmail.com mike.valk@gmail.com wrote:
Interesting: http://phoronix.com/scan.php?page=news_item&px=Google-Building-OSS-TPM2
yeah, very. means they no longer trust third party proprietary TPM implementations, which is in and of itself all we really need to know.
There isn't only that. You also need to force the hardware to use the TPM. ChromeOS probably already does that.
Using an ME to do that is not compatible with freedom. When there is no ME, BIOSes and UEFI typically set the bootblock read-only and have code in there to start using the TPM. Otherwise there is no way to prevent a malicious user to replay a good boot to the TPM while a totally different boot software was used.
There are patches for flashrom that are being reviewd AFAIK for adding the ability to set flash zones read-only. Note that "read-only" can have different meaning: - The zone can be forever read-only - The zone can be read-only if the write protect pin of the flash is grounded. - The zone can be read-only until the next boot or reboot.
On x86 hardware, the chipset can also be programmed to do make zones of the boot flash read-only until the next boot.
AFAIK chromeOS uses the flash read-only features to do it, while typicall BIOS/UEFI uses the chipset's read-only features or the ME.
now let's see if they create an SSD with full firmware source code available. the first low-cost SoC with on-board RAM, ability to connect to multiple eMMC ICs and a USB3-OTG would do the job.
They probably don't trust SSD and most storage device either.
Given that: - Most storage devices (HDD,SSD,USB keys, SD, microSD, etc) have non-free firmwares. - GNU/Linux probably trust storage devices by default. Storage devices could easily detect (by looking at the access pattern) what program/os is accesing a given file. That probably leads to TOCTOU attacks. - The boot flash(which has libreboot/coreboot/The BIOS/UEFI/etc) has no firmware so far. As far as I know it's only hardware.
You don't have many options left if you want to avoid such attacks. ChromeOS chose to verify the kernel+(initramfs?) from code that is running from the boot flash and then to use dm-verity for the filesystem.
A fully encrypted rootfs (no /boot in clear) is also a possible way to workaround such issue. Libreboot (trough GRUB) can support such thing.
At the end of the day it's still a pain because you also need to wory about protecting the device at installation time...
I'm working on a script[2] that build an image with the following softaware to address the issue: - Coreboot - SeaBIOS and iPXE - GRUB
It fetches a GNU/Linux distribution kernel and initramfs (used in netinstall images) in the computer RAM and then computes the checksums. It's then up to the user to boot the images or not, to verify that the checksums are the ones expected.
So far I've been able to bootstrap debian from it but I've still some issues to fix: - Debian is not FSDG compliant. Parabola and Trisquel don't publish kenrel+initramfs images for the installer. I should ask them. - Installing a fully encrypted rootfs without /boot in clear doesn't seem to be supported in the netinstall, so you need to do some crazy hacks to workaround that. - Installing parabola from that debian install is also not very convenient as you need to download,verify and chroot inside the liveCD. - I've some issues with the default framebuffer driver used in debian on the Lenovo X60.
On typical SBC things are even worse if you have no other choice than booting from the uSD.
However the EOMA68 has a NAND flash, which AFAIK has no firmware. I don't know the boot order on it[1]. Having a recovery parabola installer there might be a good idea since one can then *very easily* pacstrap to another (fully encrypted) storage device.
References: ----------- [1]https://linux-sunxi.org/BROM has some generic information. Using NAND with an SD/microSD card wired as MMC2 seem safe, but I don't know if the uSD is MMC0 or MMC2 in the EOMA. [2]The script will be pushed at https://framagit.org/GNUtoo/coreboot-os-installer The commits need to be cleaned up, so the history might be rewritten at some point.
Denis.