On Mon, 16 Mar 2020 06:05:49 +1100 Andrew McGlashan via Dng <dng@lists.dyne.org> wrote:
> Actually, we've got more to fear with hardware [and the lower level > firmware / EFI / SecureBoot / IME / vPro and other crap] these days > whether we avoid Winblows or not. > > The Intel and AMD flaws, Intel Management Engine (IME), vPro > capabilities and all of that crap; how can we trust our computers? > Those run below the OS level and can see everything that the OS does > and it isn't vice/versa. > > There are some outfits that go out of their way to give you back > freedoms that you should not have lost; including System76 for one, > disabling IME as much as is possible and using Coreboot. There have > been other projects in the past, but some with very, very old pre > Intel Core hardware. Almost every computer sold since the early > Intel Core Duo CPUs have had serious flaws and components/systems > that significantly lessen your freedoms and invades your privacy at > the same time -- if they don't do that, they sure can if they want to. > > Even if you bought almost any new computer these days and ran an OS > of your own making; it will still include all the Intel Management > and/or other crap. > > The latest round of flaws from Intel make it so that only the very > latest processors are immune to serious problems relating to the lack > of security of IME system keys; meaning that bad code could get on to > the machines whilst masquerading as valid, secure and signed "Intel" > code (whether you trust Intel or not). Even having fixed this > particular flaw, assuming they have, then you've still got to trust > Intel. Well, if freedom is what your after and then I assume you are only using software you have the source code to. If that's the case then there is really no reason to use the X86 arch. Most people are only stuck to the X86 arch because they need to run Windows or run some windows binary. When you have the source just run it through a cross-compiler like GCC and target whatever arch you want to use. On the mobility side we have the excellent and extremely power efficient aarch64 cpus like the RK3399. And on the workstation side we have the POWER9 cpus like the ones from IBM. http://opensource.rock-chips.com/wiki_RK3399 https://www.theobroma-systems.com/som-product/rk3399-q7/ https://www.theobroma-systems.com/evaluationkit/haikou-q7-dev-kit/ (atx form factor motherboard for aarch64 with PCIE and sata) https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/content/TL2B01/intro.html https://git.raptorcs.com/git/ Regarding cleaning out the intel backdoors from older hardware, Generation 2 (Core2) cpus can have the ME blob completely removed from them will no ill effects. Generations 3 and up to and including 6 (Skylake) You can 'neuter' the backdoor but not fully remove it. You do this by removing every module except the ones that are now required to start the main cores (like BUP for example) and setting the undocumented 'HAP' bit which was found to be sit on dell machines going to the US government. https://github.com/corna/me_cleaner Thankfully most X86 boards nowdays are not rolling their own BIOS firmware and instead just modifying some template AmiBIOS licensees them so you don't have to do a whole lot of reverse engineering to do this, however do still note that X86 cpus are like swiss cheese when it comes to security and correctness and you're still going to have all those hardware vulns like meltdown,spectre,l1tf,mds,spectre_v2, and the list just keeps on growing and growing. But this may be a stop-gap if you /really/ need to get an X86 machine you already have running. My advice is to stop buying X86 in the future and invest in other arches. -- ________________________________ / All generalizations are false, \ | including this one. | | | \ -- Mark Twain / -------------------------------- \ \ /\ /\ //\\_//\\ ____ \_ _/ / / / * * \ /^^^] \_\O/_/ [ ] / \_ [ / \ \_ / / [ [ / \/ _/ _[ [ \ /_/ _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng