[lowrisc-dev] Ideas for system integrity protection

Reinoud Zandijk reinoud at NetBSD.org
Wed Feb 25 18:23:20 GMT 2015


Hi Eve, hi Alex,

disclaimer: i am not claiming to be an expert on `trusted' computing at all :)
But i've been bitten a few times by crappy design so i tend to keep things
simple and without hacking in existing things.

On Tue, Feb 24, 2015 at 09:30:40AM +0000, Alex Bradbury wrote:
> On 23 February 2015 at 00:40, Eve FooBar <eve.foobar at gmail.com> wrote:
> > Having recently discovered Qubes-OS and Anti Evil Maid I've been reading
> > up on x86 trusted boot and find it shocking how many little flaws it has
> > that add up to it being near worthless. As such, I'd like to propose my
> > own take on trusted boot and other aspects of system integrity protection.
> 
> Thanks for your email. I am familiar with Qubes, but hadn't seen their Anti
> Evil Maid work.
> 
> > First, processors should have a dedicated minion core running an extremely
> > simple, well tested firmware capable only of taking and storing SHA256
> > hashes, the hash to be changeable with firmware upgrades if/when SHA256 is
> > broken/upgraded. This minion core then has read only access to all system
> > memory, including CPU caches and nonvolatile firmware storage for all
> > other minions. Its own firmware storage should be exposed read only to a
> > hardware pin for external verification. This minion core would then have
> > its own external bus directly to a TPM or equivalent security chip.
> 
> This is line with our current thinking, that a 'master' minion core would be
> responsible for initial boot.

Yes, in the current proposal this `master' minion is also the DMA engine/IOMMU
controller and gatekeeper. It boots itself from the (external?) FlashRAM,
initialises the other minions and then loads the application CPUs with the
Hypervisor. This software is considered part of the board and when the SoC is
comitted to a piece of external hardware, it will at most get firmware
updates. Each minion can't access neither (other) minions memory nor base
memory; transfer of data can only go by *requesting* it to the `master' minion
to be transported by the `master' minion's DMA engine if accepted.

As for the FlashRAM, only the `master' minon can access it and unless
explicitly programmed and catered for it to be uploaded from application
space, i forsee updating the flash only to be done with either externally
hooking up SPI for direct programming or by uploading it trough a serial
console attached to the `master' minion (one that might not even be there in
the production version). One has to draw a line on external tinkering
somewhere :-/ Embedded FlashRAM with a once-burned in `secret' could be done
but then we're getting into paranoia.

As for the chain-of-trust, i'd say FlashROM to `master' minion, the other
minions programmed by it, the embedded Hypervisor and then the OS and
applications.

In order to be safe the `master' Minions tasks should be kept simple and
testable.

> > In order to protect against DMA attacks, the IOMMU should also isolate all
> > DMA devices by default, configuring each device with a small, unshared
> > buffer so that the system can't be tampered with between trusted booting
> > and OS configured IOMMU protection can be enabled. This would mean that
> > not all minion cores would need to be untampered with to boot securely
> > (that's why there's non critical hashes above), allowing use of still
> > trusted features of the system while awaiting repair.

As all communication between the Hypervisor and the Minions (and between all
Minions) are envisioned to be going trough a FIFO chain and all data transport
going trough the `master' Minion's DMA engine, an IOMMU is less needed;
Interrupts are only served on message receive and no memory mapped devices are
available on the application CPUs side.

Furthermore, each Application CPU has a small kind of extra MMU in the
proposed scheme that strictly isolates each `OS' from eachother. If a secure
software component is to be running on the Application CPUs it can be isolated
this way too and provide its `devices'/services trough the Hypervisor to other
parts as if it was programmed in a minion; think of f.e. hi-speed encryption
services.

> > Finally, a means of preventing unauthorized write access in the first
> > place is needed. One way might be to have a dedicated minion core with
> > exclusive write access to all system firmware, including a store for the
> > system's boot partition. Another might be an equivalent to ARM's
> > TrustZone, with only the secure context getting write access to the
> > firmware and boot stores. Either way, when booted to allow firmware
> > upgrades, invoked by a hardware switch only, the system will use the trust
> > minion core to verify the secure operating system and any
> > firmware/software it relies on, then enable users to select firmware
> > images designed for different parts of the system and verify cryptographic
> > signatures on them before flashing to the chip and resealing the TPM.

See above!

With regards,
Reinoud

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
Url : http://listmaster.pepperfish.net/pipermail/lowrisc-dev-lists.lowrisc.org/attachments/20150225/28df8a3b/attachment.sig


More information about the lowrisc-dev mailing list