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.
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.
l.
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.
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
On Thu, 8 Dec 2016 18:10:10 +0100 "mike.valk@gmail.com" mike.valk@gmail.com wrote:
Hi Dennis, you're being a bit too vague here. If I understand correctly you are trying to build a installation verification tool?
I'm just trying to build an installer that isn't subject to attacks by storage devices firmwares.
Fetching netinstall kenrel and initramfs directly from the Internet to the RAM, and then verifying it avoid using storage devices with firmwares.
Denis.
On Thu, 8 Dec 2016 18:10:10 +0100 "mike.valk@gmail.com" mike.valk@gmail.com wrote:
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.
It is also small enough to be able to be kept with you most of the time.
Denis.
arm-netbook@lists.phcomp.co.uk
-
Denis 'GNUtoo' Carikli -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com