[Arm-netbook] Opensouce TPM

[Denis 'GNUtoo' Carikli]

On Thu, 3 Nov 2016 10:28:22 +0000
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> On 11/3/16, mike.valk at gmail.com <mike.valk at 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.