- 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.