X-Git-Url: https://totsipaki.net/gitweb/Published.git/blobdiff_plain/b12379b29dfb1c18261f02d3822fb7f887884654..e0d5d4ef4b80ba2fee79a85c30eec1b2c4fb0138:/BlackBoxInside/GNUTOO.txt?ds=inline diff --git a/BlackBoxInside/GNUTOO.txt b/BlackBoxInside/GNUTOO.txt new file mode 100644 index 0000000..bbdc720 --- /dev/null +++ b/BlackBoxInside/GNUTOO.txt @@ -0,0 +1,412 @@ +- 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. + +