2016-11-23 18:21 GMT+01:00 Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>:
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.

Probably nothing on the open market. EOMA68 comes close. But does not have tamper protection. It does however give to option to verify every aspect. Making it tamper protected would make this even harder exercise even more difficult.

The issue is that we work with complex systems. There is no longer one single CPU. A lot of parts are timing sensitive and are general purpose, power management, communication. Even within the SoC. The cheap solution is to use general purpose microcontrollers are used opposed to build logic systems from ground up. Building logic systems is expensive and time consuming. Writing software is fast(er) and cheap(er).

Every microcontroller is a "computer" on it's own. And thus an attack vector.

Attack vectors for EOMA68-A20 that I see:
1. Microcontrollers in every USB connector. (But that's an vector for all systems)
2. A20 has a RISC cpu inside for power management purposes. Not used by currently iirc. But not checked either.
3. The PMIC is an Microcontroller with firmware
4. The housing has a ARM microcontroller. Which runs it's own RTOS. 
5. Audio attacks on the sound stack

The list for Intel machines is miles longer though and more profitable. Which is a large item in assessing the risk
 

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

Hi Dennis, you're being a bit too vague here. If I understand correctly you are trying to build a installation verification tool? 
 

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.

Check the schematics I'd say ;-)

IIRC the flash controller is hardware and controlled from Linux. With eMMC, which is not used, There is a microcontroller controlling flash much like SSD's
 
[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.

_______________________________________________
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@files.phcomp.co.uk