[trustable-software] I fear we need trustable hardware too...

Niall Dalton niall.dalton at gmail.com
Fri Jan 5 17:21:37 GMT 2018

On Thu, Jan 4, 2018 at 9:51 PM, Andrew Banks <andrew at andrewbanks.com> wrote:

> Agreed... and this is particularly true about the micro-code (or whatever
> you want to call it) running at the lowest level - often in devices that
> one may not expect to have processors in!

‚ÄčIt might be worse than you think.


1) microcode of a particular CPU
2) interesting modes of particular CPUs
3) 'expected' other processors and software layers
4) 'unexpected' processors on the system

For #1, typical high end CPUs (esp. x86) do not use hard-wired logic for
all the architectural instructions (the stuff in the manuals). The core
actually executes "micro-operations" (uops). Some instructions are
translated, on the fly in the front end of the processor, into a sequence
of uops. Basically there's a set of match registers, if you put a value in
one, and it matches against the incoming instruction stream, it'll issue
the associated sequence. They do this for two reasons - partly to allow
easier implementation of complex multi-stage instructions. And partly so
that they can modify the core after the fact in case of bugs. Attacks have
been demonstrated where, for reverse-engineered and modified microcode,
benign looking instructions are given malicious side-effects. E.g. some web
browser does a multiplication, and for certain values, the machine goes and
does weird things...

For #2, I'll stick with x86. There's multiple 'rings' of privilege. Normal
code in ring 3. Ring 0 is the normal OS. Ring -1 is there the hypervisor
lives (a hack beneath the traditional ring 0). But there's also "system
management mode", in ring -2. You can't see what it does. You can't see the
memory it uses (it's reserved as the system first comes up and the memory
controller blocks access to it. It's a magical place. If the system takes
an SMI interrupt, it enters SMM mode and does unknown stuff with private
memory. Except.. when local APICs where added, which we can fiddle with, it
allowed us to redirect memory access that the code in SMM is doing, and
rewrite the global descriptor table. Ooops. How bad is this? Well, Intel
TXT is sometimes used to provide a chain of trust. You can use what is
supposed to be trusted hardware to verify that the os kernel or hypervisor
you are booting is unmodified. Except TXT depends on SMM. Root SMM, and you
can lie to TXT, which will lie to the user about trust of their loaded OS.

For #3, there's the usual hack-the-BMC and IPMI implementation.

For #4, which you allude to, there are the 'extras'. In older generations
of x86, this was an ARC4 microcontroller, for example, in the PCH running
ThreadX. In more recent machines it's an x86, think 486/p54 class, running
MINIX3. It sits between the main x86 and the io devices. Boots when power
is applied (even if the machine is 'off'), and has magic access to
everything flowing through. Hack this, and you can get data, but you can
also attack the chain of trust for UEFI. You can do it from across the
network, while the main machine is 'off' (but power is applied to the
board). This category of extras should also include the controllers on
network cards, storage cards, etc.

Fun and games all the way down.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180105/5c178a0a/attachment.html>

More information about the trustable-software mailing list