[Libreboot] Audit Was: Can libreboot help to escape the Intel AMT/ME nightmare?

[Denis 'GNUtoo' Carikli]

Background information:
  AMT: One of the *many* firmwares that can run on the
       management engine. Before running on the management engine, they
       ran on the Ethernet NIC.
  ME: The ARC CPU running one of theses firmwares. It has access to
      your RAM.

  Note that I didn't work on the x200 but on the x60.

On Thu, 05 Feb 2015 12:17:31 +0100
Alexander <address@hidden> wrote:
> Is there an indication that a flashing the bios with libreboot will
> allow to disable
> Intel AMT?
Yes there is, I'll let other people respond to that.

> If this was so, is there any technical mean (i.e. a multimeter or
> other technical device,
> which would allow me to confirm this with some reliability).
If you just want to check for AMT, it's quite easy. AMT can be
interacted with over the network and it's loaded from the BIOS flash.
So wipe out the ME region and test against it by interacting with AMT
before removing it, and trying to after.

The issue I fear the most is "we don't know what we don't know".
what if the bootrom of the ME had evil stuff? What if that chip was
still active somehow?

> For good or for bad there is some paranoia.
Well, given that we don't know everything from the agencies and so on,
if you lack evidences and so on, you go by speculation and "paranoia".

> Is there any way to gain
> some trust
> to other users? I think no other technical mean would allow to get
> trust, than to
> bunch up with other users to get to know each other personnaly well
> enough and
> to henceforth trustfully devide the work of auditing.
Personally I'm not very comfortable with having such chip inside my
main laptop. Even if you find a way to be sure that it's off, if
someone penetrate your computer one day, then the ME would be a
tempting target.

Now the i945 libreboot laptops such as the X60 and T60 do not have a
management engine, and they don't ship with AMT.
In theory AMT could run on such laptop, as an Ethernet NIC firmware,

So now assuming that you have an i945 laptop such as the T60, how do
you audit it?
Here I assume that:
-> the threat level are agencies.
-> you want to protect against physical tempering.
-> you read the documentation on securing your laptop.

Now the way to do it is to list the chips, list their capabilities
(DMA, no DMA, access to the keyboard, access to the network, etc) and
audit them by:
* reading their datasheet or looking for specific things into the it
  (such as DMA).
* experimenting with it.

I'll give some examples:
  LPC:
  ----
  For instance, you have a dock connector under the X60 and T60, so you
  look up the pinout and find out that there is a pin that can
  potentially do DMA. So the first thing to do is to read the datasheet
  and find out that this feature is controlled by registers. Then you
  dump the registers with superiotool and come up with a conclusion.
  But then, can you really trust the datasheets, they are often
  incorrect, incomplete and so on.

  So assuming that the DMA is disabled by software, why not go
  further and test such claim? why not buying a dock for its connector,
  interfacing it with the LPC connector of a common coreboot mainboard,
  and testing such claim for real?
  Then at this point you would have tested the documented part of the
  datasheet. Then I wonder if it's worth trying to fill the datasheet's
  gaps, like the "RESERVED" registers and bit fields?

  Also look at the chip connected to the external connector with
  potential DMA capabilities(pc-card/express-card, firewire, etc)
  You can prevent your distro from enabling them, but you could also
  verify that they are really disabled by testing such claim.

  Also you could look at what chips still have a firmware, and look at
  what they have access to.
  Example: the embedded controller has access to your keyboard but not
  to some network.
  Still even without a network it could be dangerous: if the attacker
  is able to modify such firmware, he/she could make the firmware try
  to transmit signal, for instance trough a GPIO, or some other I/O
  that an SDR nearby would receive.

  As for documenting it, I guess that patches against the documentation
  should be OK. If you do such audit too, please publish what you find.

  If you prefer another way of publishing such information (wiki
  etc...) please tell too.

Denis.

pgpmiAVBWOxxI.pgp
Description: OpenPGP digital signature