Merge remote branch 'Published@totsipaki.net/master'

[Published.git] / BlackBoxInside / GNUTOO.txt

- As for the software and hardware boundaries, Alexandre olivia also
  has 2 interesting articles on the consequences for freedom of various
  cases: 

  https://www.fsfla.org/ikiwiki/blogs/lxo/draft/blob-fallacy
  https://www.fsfla.org/ikiwiki/blogs/lxo/draft/unshittify.en.html

  It might be interesting to take that into account somehow for a wider
  discussion and also look at the risk of nonfree software in different
  cases.

Table 2.1
---------
PT Security also had also very long articles on the topic in their
blog. They also contains more background on the 'disable' bits like Alt
disable, like why they seems to have been added and so on.

2.4 Accessibility
-----------------
With:
> and prevent playback of audiovisual material by applying Digital
> Restriction Management (DRM) [Ruan, 2014][6].
and:
> [6] Page 49

I didn't manage to find that claim. The reality being described is a
bit different: it can display things on the screen that cannot be
copied by the operating system probably either by displaying things to
the GPU directly (Intel EPT with the keypad example page 49), or in the
next page by injecting encrypted frames along with the decryption key
to the GPU.

So here it doesn't really prevent the playback, it rather enables
playback at huge freedom costs (basically loosing the control of your
computer).

So maybe the sentence could be reworked a bit by telling that it's
involved in DRM and telling a bit how.

Otherwise readers might think that I want to play some forbidden video
like a video from a resistance group in a repressive country, and then
somehow the Management Engine would prevent me from doing that.

Maybe it could but I'm not aware of it having done that so far.

My feeling while reading the book chapter on DRM is that there is some
advocacy/justification for DRM, so it might be a good idea to try to
rework the sentence in a non-neutral way that is against the DRM.

I also have a feeling that DRM is the main cause why we have things
like the Management Engine / TrustZone, etc on all consumer devices and
that we cannot replace the nonfree boot software with free software. 

It might be less relevant for x86 as the history of the Management
Engine is not directly linked to DRM, but on smartphones I think that
the link between DRM and operating systems running in TrustZone (and by
extension signed bootloaders that loads these operating systems) is
stronger. But I was only given indirect information on that and the
source didn't want to go on record.

2.5.2
-----
About secure boot, I think we can in theory enroll our own certificate
but at the end of the day all that is extremely complex to handle and
practical freedoms are been made extremely difficult to use.

Your article has something like that:
> When Secure Boot is activated, it is impossible to install an
> alternative bootloader (see chapter 4).

Here people will think that with UEFI Secure Boot you cannot install
GRUB and that Microsoft said so. And the Chapter 4 doesn't talk about
that interpretation all, and only talks about free boot fimrware
(distributions), not boot restrictions.

Here this seems to be because:
(1) There seems to be 2 meanings of secure boot. One is the UEFI Secure
    Boot standard, and another could be the a chain of trust that
    starts in hardware. Here you mean the second one.

(2) Bootloader is typically associated with GRUB running after the
    BIOS or UEFI.

Here's an example of modification:
> When a hardware chain of trust that enforces signatures is enabled,
> works (its security is not broken), and that users don't have the
> signing key nor can bail out of that, it is impossible to replace the
> boot firmware. Chapter 4 will show free software boot firmwares.

Also there a correct technical term for GNU Boot would probably be a
'free software boot firmware distribution', but 'boot firmware' can
be confused with 'WiFi firmware' or 'CPU Microcode', so I tend to use
boot software instead. But 'distribution' is important (more below).

In practice the term bootloader seems to be used in x86 for GRUB that
runs after the BIOS or UEFI, but also for 'u-boot' that does the same
than GRUB + BIOS/UEFI, so it's a bit messy.

As for the broader context GNU Boot and Libreboot are distributions,
like Trisquel, Guix or Parabola. The only difference is that we package
(and sometimes deblob like in the case of GNU Boot) software like GRUB,
Coreboot, etc.

As for what does what I think it might be interesting to avoid
confusions: Coreboot's code only initialize the hardware, and is
incapable of booting an operating system. So during the build it also
download, compile and include a third party software that know how to
load an operating system. You have several options like:
- SeaBIOS: A free BIOS implementation.
- Tinaocore: A free UEFI implementation.
- GRUB: A bootloader that can boot many operating systems.
- etc (there are more).

And distributions like GNU Boot or Libreboot package all that, and ship
binary images that users can test and install (Coreboot doesn't ship
any binary image). We also go further than Coreboot as we try to
release an image that is directly usable by users without having to add
more configuration and so on.

As for UEFI secure boot, the social aspects of that is also extremely
interesting here. For instance despite the "security" constraint for
free software, the fact that some known nonfree boot software was signed
and didn't implement signature verification or another scheme seem to
have been completely tolerated:
https://mjg59.dreamwidth.org/60248.html

Another interesting thing I came across is that to make BIOS/UEFI
updates work when the user had the TPM enabled, the vendor simply added
a backdoor for the update. There was a security talk about it. In
contrast here too we struggle to use the TPM properly within free
software, especially because of these updates...

2.5.4
-----
About using the Management Engine for security if it was to run free
software, some of the 'applications' like EPID are not very useful. For
instance GNU Taler can have a better mechanism without having a central
trust on a company like Intel.

Though for remote administration it looks extremely useful but the user
would need to be aware that it's enabled or disabled somehow, otherwise
it could even be abused with free software.

Another way would be to write our own applications somehow, and we'd
probably end up with very different feature set.

For instance it could be used to improve boot security, and there is
already a wide area of research in this direction in FLOSS projects
(example: HEADS, Pure Boot, shim, etc). So moving part of it in the
Management engine somehow could make sense. In addition the TPM is now
an application, so a lot could be done by combining all that.

Though the question here would also be to understand how well the
Management Engine itself would be protected from the rest of the
system else there would not be much point into using it for such
schemes (and there are also other schemes that are less dependent on
preventing privilege escalation).

3.2.1 Marketting in technology
------------------------------
While I completely missed the marketing aspect before reading your
article (thanks a lot for that), I think it's not the complete picture.

I think that the nonfree software model badly needs a lot of these
security features, and that even free software can also benefits from a
small subset of these features (though without depending on them too
much, an example would be the NX bit or similar code flow integrity
protections).

If we just look at the basics, we have some huge differences between a
free software OS and a nonfree one. If we assume the distribution model
for free software and not appimage or software shipped directly by the
developers, the distributions trust the applications they ship not to
be malicious whereas nonfree software usually doesn't.

This doesn't mean that checks are not done before shipping (the XZ
backdoor was caught before being really useful for its creator for
instance). But once shipped it's trusted, and this changes things a
lot (more on that below).

In contrast for nonfree software addition there is usually both a
commercial imperative and the ability to hide things (like security
flaws, backdoors, etc). This could be done for legitimate purposes for
instance to do a BIOS update with while keeping the TPM working, or not
to fix some security issues (because they cost money) and only fixing
the most important ones, or even have semi-legitimate uses that
can also be considered malicious, like drivers for forensics hardware
and so on but that are meant to be limited to some states / organization
only (though in practice this is not always the case).

And commercial imperative + the ability to hide things also mean that
companies writing driver for nonfree operating systems also have the
same incentives, and even when caught, they could pressure the nonfree
OS not to blacklist their driver, or at least be that important for the
survival of that operating system that they cannot be blacklisted,
without having to do any pressure themselves.

The combination of all that (users installing whatever + unfixed bugs,
and backdoors) makes it way more likely to have full compromise of a
device with a nonfree OS than with a GNU/Linux distribution where users
only install software they trust (usually from their distribution and
that's all). So when you add the ability to run untrusted code to all
the mess in the nonfree software case, the untrusted code can exploit
old buggy drivers that are signed and so on, and get full device
compromise.

In addition in nonfree operating system like Microsoft Windows there is
also a big issue with things like drivers that was already present in
DOS at least: people writing software For Windows or making hardware for
Windows often need to modify the system in some ways. But the operating
system is nonfree. And Microsoft probably doesn't look at driver
source code (unless it's free software and needs to be signed somehow).
So you can even have some attack surface there as the drivers can also
be untrusted.

If we look at how UEFI secure boot is managed (like explained in the
article from Mathew Garret (mjg59)), we can see a bit of all that.
Anti-virus are also known to whitelist some software (like the Sony
rootkit back in the days).

So all that looks like a nightmare to secure, so if you assume that
Microsoft doesn't want to switch to free software, having more
and more security features in the hope of reducing the damage enough to
make it acceptable by users would be a good plan for them.

In the case of Apple they probably managed to limit way more the attack
surface: they make the hardware and the OS for instance, so they can
have less driver issues if they want, and they can probably restrict
more what applications can do, but that's at the expense of users
practical freedom (users are stuck with their hardware and so on), and
it doesn't remove all these problems at all (I guess they have similar
issues with the drivers they don't have leverage on, anti-viruses that
probably need privileges and that are badly written, and so on). And
here too there is untrusted code everywhere. The most extreme
version of this approach here is probably the ipad and iphone where
users don't have any freedom left (they can't run the application they
want). And yet malicious untrusted applications can still exploit their
data as long as they don't attack the operating system.

And so if you're Microsoft, the attack surface is bigger, so a
potential solution looks exactly like the model of the Management
engine: you implement security features in some place that is somewhat
isolated from the rest of the system, with lower attack surface and
that has higher privilege to be able to do something meaningful for
security. The HVCI feature mentionned in the article about BlackLotus
you mention seem to be something like that too.

And it's not limited to the computer, since everything uses that model
you end up with packet sniffing / IDS outside of the computer, etc. And
that again can easily be evaded. So you've got layers on top of layers
and it gets more and more complex to secure. So now there are
new security solutions that try to tackle the complexity, to even
infiltrate group of people that attack computers, to try to gather
'intelligence', and also use statistics and information gathering, etc,
to predict what the attack will be to better counter them and so on.

In contrast in GNU/Linux the issue tend to be less severe since people
typically contribute upstream directly, though we also have some out of
tree free drivers of very bad quality that are often shipped in
distributions (usually not in FSF approved one since they typically use
nonfree firmwares), but then users would either need to run untrusted
code that then reuse these to do privilege escalation or to be close to
the attacker (like in the case of a bad WiFi driver or even firmware).

So that limits the risk a lot. Though things are far from perfect.
Computers are too complex to be properly secured against some very
simple use case like opening a document that you don't trust. For
instance someone that does political dissent usually needs to
open documents from unknown people. And sometimes these document have 
0 days in them, and it's possible because document formats are hard to
parse (harder than network protocols for instance). But for most people
things are fine. 

And selling 0 days probably earns more money than basic computer crime
/ delict anyway, so that kind of shields the general population against
wider attacks under GNU/Linux.

3.2.2.1 CVE
-----------
It's also worth nothing that nowadays a company can manage their own
CVEs, and some free software projects started to do that. I'm unsure
of the impact as I've no idea how in practice this affects things. For
instance it may be possible to still fill the CVE not directly to the
company. Reference: https://lwn.net/Articles/961978/

3.2.3 potential security hole that remains pernamently active
--------------------------------------------------------------
Here a reply to Intel would be to look at what happens in practice with
things like the HAP bit that is used by me_cleaner.

The research of PT Security and of people that looked at its use point
that it was made for security critical systems: by setting that bit,
the operating system (minix) boots and at some point stops loading
extra applications.

This means that at least part of the united states governement agrees
with the free software community by classifying the Management
Engine as a security risk. If I recall well Dell also sold computers
with that bit enabled, for similar markets.

The part about disabling AMT we can somewhat verify the me_cleaner part
as some ME operating system versions have been analyzed partially by PT
Security and others. 

But a lot remains not-analysed: they only analyzed very specific
versions of the Management Engine AND only very specific parts inside
these specific versions.

So we know what the HAP bit does or is supposed to do but not much
more. We don't know what all the code that runs before the evaluation
of the bit does exactly. It probably initializes some hardware for sure
but we lack source code and a community behind, and also the practical
freedoms like the ability to modify the code, to do proper research.

3.2.4 backdoor
--------------
It might be interesting to point out real world use case(s) as a
backdoor like PLATINIUM to show that it can really be used like that:
https://en.wikipedia.org/wiki/Management_Engine#PLATINUM

4.1 Is AMD s Smarter Choice?
----------------------------
I think it could be improved a bit by telling that AMD *competes
(mostly) in the same market* or talk about market somehow.

Because otherwise there are *a lot* of alternative, like ARM or RISCV
computers, but it's not the same market.

For instance it's extremely complicated to find ARM computers that are
in the same range than Intel/AMD with price range, power consumption,
computing power, extensibility (many PCIe ports, SATA), etc.

4.3 Free computing systems
--------------------------
The I945 Thinkpads don't have a Management Engine and AMT was not
enabled by the manufacturer (it's supposed to be in the Intel Network
card for I945). So GNU Boot doesn't change much here beside replacing
the BIOS by free software, which also removes a rootkit along the way
(named Computrace). And that rootkit had also known security
vulnerabilities. But as I understand it is supposed to only affect
Windows, but again we don't have the Lenovo BIOS source code.

For GM45 it's a bit different, the boot flash has a partition table
(called Intel flash descriptor, or IFD) and we simply configure that
not to have an ME partition.

Here's an example:
> $ ifdtool -d grub_x200_8mb_libgfxinit_txtmode_usqwerty.rom 
> [...]
> Found Region Section
> FLREG0:    0x00000000
>   Flash Region 0 (Flash Descriptor): 00000000 - 00000fff 
> FLREG1:    0x07ff0003
>   Flash Region 1 (BIOS): 00003000 - 007fffff 
> FLREG2:    0x00001fff
>   Flash Region 2 (Intel ME): 00fff000 - 00000fff (unused)
> FLREG3:    0x00020001
>   Flash Region 3 (GbE): 00001000 - 00002fff 
> FLREG4:    0x00001fff
>   Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)

So you have a lower bound and an upper bound to the partition and in
the case of the ME there are special values to tell to disable the
partition if I recall well. These are the '00fff000' and '007fffff'
there. Here there is also a Platform Data partition that is disabled.

In contrast if we take the partition table itself, it starts at
0x00000000 and ends at 0x00000fff and 0xfff is 4KiB, and it's size is
4KiB once extracted. The Gigabit Ethernet is 12K (0x00002fff -
0x00001000) == 12KiB.

So when we replace the content of that flash chip, it also erases the
Management Engine OS along the way. The Management Engine most likely
has a ROM though. And the GM45 one wasn't dumped as far as I know.

The problem that we have is that on more recent computers the code that
the Management Engine runs initialize some hardware, and more and more
code is needed. So removing it either results in an unstable or
non-booting computer.

I suspect that disabling the Management Engine was unofficially
supported by Intel somehow for the GM45, and I was told it stopped
being supported at some point because of cost reasons: it costed less
to have software to workaround hardware flaws at boot than make the
hardware work properly from the start.

4.3 Free Computing Systems
---------------------------

I think that for ARM there might be more powerful servers that could
also work with fully free software but I didn't investigate them. Back
in the days Paul Kocialkowski looked at some of them. But as said before
these are not the same market than x86, so it's not a drop in
replacement.

Computers made with KGPE-D16 mainboards can also be the fastest x86
computer that boots with fully free software (though users need to not
use external ATI/AMD/Nvidia GPUs else that will run nonfree software).

There are also RISC-V computers. 

The use case is also important to consider because you don't need
external GPUs in servers whereas for workstations you typically need
one or more screens so you need at least a good display controller and
ideally a GPU.

PS: Can I also send the link to neox who also co-maintain GNU Boot with
    me? It might interest him to read or review it as well.

Denis.