+- 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.
+
+
projects / Published.git / blobdiff