With the good folks, like @justmike80386, @mike_banon, et al, restoring the full strength of the Pre-PSP-corebooted KGPE-D16 motherboard, it is now at the top of my list for choice of an owner-controlled, secure, Qubes OS system.
However, I wanted to question a proprietary Boot ROM entry for the KGPE-D16, and other boards, listed in Dodoid’s Computing Freedom Table (DCFT)…
For the KGPE-D16, the DCFT says (in red):
- Firmware: Boot ROM = Proprietary
What exactly is this proprietary Boot ROM entry, and is it a security concern?
Is this just referring to the physical BIOS ROM chip itself (such as a Winbond BIOS chip), which coreboot is flashed onto?
Or is it referring to some binary blob needed within a ROM image to boot the D16 machine? Or maybe something else?
My guess is that this is just referring to the physical BIOS ROM chip itself, which coreboot is flashed onto (and therefore harmless), and that the only binary blobs associated with a corebooted KGPE-D16 are then the CPU microcode updates and the option roms (optional proprietary VGA, etc)?
Wanted to be sure, so asking the community of those who may know better.
I believe you’re the first person to notice DCFT! It’s relatively new and there are several things I would still like to add to it. The “Boot ROM” column was included to account for systems which include initial firmware in on-chip mask ROM or OTP, begin execution there, then use that to find and load additional firmware/a kernel (e.g. from SPI flash or an SD card). Examples of this include the (free) OTPROM on POWER9, and the (proprietary) BROM on Allwinner SoCs. DCFT is not Qubes-specific, so it tries to be able to account for lots of non-x86 quirks.
The thing is, to my knowledge, x86 doesn’t do this. The only thing I know of sort of like it is, if your Intel machine uses Boot Guard, it begins execution in the ACM (which the ME has already loaded from flash and verified) rather than executing directly from flash, but that’s far from universal. For fam15h specifically, I just had a look over some of AMD’s documentation for the southbridge (which includes the SPI ROM Controller) and the platform as a whole (the BIOS and Kernel Developer’s Guide), and I’m honestly not sure why I marked Boot ROM as “Proprietary” rather than “None” in machine/template/x86. Again, DCFT is quite new and rather incomplete.
I have corrected this in the x86 template, and added a “detail” clarification to appear on relevant pages, plus additional information regarding the ACM in the Boot Guard template)
Interesting. I thought disabling it via HAP is thorough.
Is this description from NovaCustom not correct (or incomplete)?
The second method is the HAP disabling method, which involves disabling a bit that acts like a kill-switch. This method has gained popularity in recent years, and for good reason. The HAP disabling method is considered more secure because it’s a hard-disable method that completely turns off Intel ME. The open source community has tested and verified this method of ME disabling, making it a trusted and reliable way to disable Intel ME.
It does cause the ME start reporting that it hasn’t booted fully. The complaint is that, unlike the older method of partially (or on older-still systems, fully) removing its firmware, there’s no real way to confirm that it couldn’t run normally, only that it’s reporting an abnormal state (with e.g. intelmetool) - the stock firmware is still THERE, you’ve just asked it not to boot fully it has told you that it hasn’t.
Some people (generally those who believe the ME’s primary goal is to provide a backdoor) believe that the HAP bit is a “placebo”, or that at some unknown time it became one. The ME’s functionality hasn’t been a complete black box for close to a decade by now (partial reverse-engineering of its firmware is pretty old news), but to my knowledge nobody has looked closely at how newer ME firmware actually implements the HAP bit/Alt Disable Mode since its initial discovery. To me, at least, it’s relatively clear that in ME11, where the HAP bit was originally discovered, there is enough documentation to be confident that it works as intended. I’d be curious to know if anyone’s checked later firmware since then.
The definition of neutered is derived from Purism:
The rest of the attack surface of Intel (CS)ME remains even if it may have been hard-disabled via HAP bit or soft-disabled the HECI method, in contrast with neutralized/neutered, where removal of various components to reduce the attack surface are implemented. These two states may be combined, as concluded in the Positive Technologies blog article linked above, although the removeable components may differ between versions.
Thanks @Dodoid for this detailed overview & explaination on this. Very informative. And good to know that we don’t have to worry about some other blob ROM chip in the boot process of the KGPE-D16.
Confirmed update to DCFT:
For the KGPE-D16, and others, the DCFT says (in gray):
- Firmware: Boot ROM = None
The DCFT is a truly great resource, and the way machines & platforms should be presented, for security interested people. Looking forward to its expansion in the future and seeing others take notice too. Great work!
@FinBob, yes @FranklyFlawless got it, as the Intel ME is the issue for NovaCustom laptops. And the same ME/PSP potential backdoor issue exists on all other recent Intel/AMD coreboot-industry products being sold I’m aware of.
NSA’s HAP bit is not trustworthy for killing the Intel ME. Especially true in newer generations after the NSA’s HAP bit discovery, as they could just create HAP bit #2 and use HAP bit #1 as a false or incomplete switch, or any number of other deceptive techniques.
Unfortunately, the coreboot-industry has apparently mostly taken a position of trusting Intel/AMD/USGov to not be interested in controlling one of the most powerful global backdoor spying platforms ever. The surrounding circumstances of the ME/PSP even look suspicious.
Trustworthiness cannot be achieved with such opaque encrypted blobs in a position of full remote control of one’s hardware.
This stuff is a true cancer to open/secure/trustworthy computing. It just shouldn’t be.
I would entertain laptops as well, if something more open/secure/trustworthy were available. I’m using it more as an appliance server, but wouldn’t mind dealing with an odd form-factor for a superior security option.
Yes, @justmike80386, this is the correct perspective to have!
To clarify my position further…
I’m in the camp of not trusting ME/PSP, as it looks like a potential doom-and-gloom global USGov backdoor.
That said, I take an agnostic perspective on belief as to whether it actually IS a backdoor or not. As nobody but intel-insiders actually seem to know for sure.
The ME/PSP sure does look spooky suspicious though…
- It doesn’t make sense for a chipmaker to deny the public an effective off-switch, but then also build-in an effective off-switch which they tell only to the NSA. There is no reason to say one customer (USGov) can decide for themselves to turn off a controversial binary blob feature due to USGov’s own security concerns about it, but take the position that every other customer (including other national governments & major corporations & individuals) can’t make their own decisions and that this ME/PSP feature only helps everyone else’s security and must never be fully disabled. They give NSA an effective off-switch because they know it is a security threat, but claim everyone else needs it and it enhances everyone’s security. Double speak position.
- It doesn’t make sense for them to build it in so deeply and blob it. They could have offered such features in different ways that aren’t so secretive and offensive. The Pre-PSP KGPE-D16 has an optional BMC addon card (iKVM) that can be plugged-in or pulled-out for remote management. The Pre-PSP KGPE-D16 also has an optional TPM addon card that can be plugged-in or pulled-out for additional boot integrity. The ME/PSP features could have been made totally optional like this, even allowing them to be physically plugged-in or pulled-out as addon cards. But, nooooo, they had to integrate them into the core fabric of the processor functionality itself, and then make the capabilities encrypted and binary blobed, so that these “features” cannot be removed or switched-off, without Intel/AMD/USGov deciding so. Intel went first in the 2000s and implemented their ME as a separate coprocessor chip on the motherboard (which allows third parties to at least work on it more directly), where AMD went second in the 2010s and implemented their PSP into the CPU chip (which even further removes it away from third parties).
- It doesn’t make sense for AMD to follow Intel down this ME hell hole with the PSP. A decade ago, when the AMD PSP was new, I recall AMD was still somewhat of an underdog compared to Intel being the bigger market giant (things have reversed with AMD on top now). I think it looks suspicious that AMD went down the same path with building the same style of backdoor-looking technology into their processors, as Intel did, except as more covert technology deeper in the physical processor. AMD was starting to go more open source with AGESA, and as an underdog could have pounded a big public relations drum against Intel for having such potential ME closed backdoor technology, where IT Managers could have viewed Intel as a liability to their company’s security (and their own company’s US tax/regulator dealings) and instead preferred AMD as being clean and safe for their companies. This mirroring behavior of Intel & AMD together feels potentially coordinated to me, like USGov experimenting with its bigger trusted national champion partner Intel first, then once the technology is stable/refined/tested in the real world, bringing the next major player AMD onboard under the secrecy of a NSL (National Security Letter) to use the same/similar backdoor spy tech.
- It doesn’t make sense for the USGov to be so cozy and integrated with big chipmakers. Very blatantly, The USGov’s NSA had their own bit flag put into Intel ME. Extremely blatantly, USGov now has direct ownership of Intel Corporation, so “Intel Inside” is not just a slogan to them. And, disclosed in the 2013 NSA documents, we learned that the NSA and intel agencies are regularly operating at insane levels and with extreme sophistication that was once thought of as crazy conspiracy theory. We now know the NSA regularly spends large amounts of money annually to specifically go out to important technology companies (and probably open source projects too) and sabotage the security of their products & infrastructure in order to gain backdoor access (by means such as implanting employees/contractors, bribes, threats, NSLs, hacking/cracking, blueprint modification, supply chain attacks, etc). Note that the CIA even started a venture capital firm “In-Q-Tel”, for what, to make money (lol)? The ME/PSP smells of “NOBUS” tech to me (Nobody But US), and Intel & AMD both digging their heels in to defend & persist this unwanted mandatory cancer for this long is also telling as an indicator.
- If I were the USGov and were to design a global computing backdoor, then ME/PSP is probably exactly how I’d do it. One can imagine more covert hidden ways of backdooring the hardware, however, part of the strength of ME/PSP is that it can exist with an open cover story, that it is a feature-not-a-bug, and has an important and intentional customer-focused purpose of remote management and platform security. Integrate enough core functionality into it, so that the system won’t operate without it, and all customers are then stuck with it whether they want it or not. Probably use some super cleverly obscure NSA remote trigger code (that could be explained as and look like an unintentional bug, for if the ME/PSP binaries were ever leaked or cracked). This external trigger would activate their remote control of the ME/PSP once the chip sees the right sequence of bits pass through it. Constant phoning home of all x86 PCs would be way to big of a red flag, so individually-targeted external triggering would be how it gets activated on a per-machine basis. Air-gaps are sacrificed as acceptable missed opportunities, or treated as hard-targets with air-gap jumping techniques. Maybe cross-mix some CPU hardware functionality with the ME/PSP binary firmware so that the full backdoor is not explicitly written in the firmware code that could be reverse-engineered, but rather an “emergent” trait of how hardware & firmware interact together.
However, strategically, in making computer hardware decisions, I don’t need to know or believe what is actually happening for certain. Rather, spooky fingerprints are apparent, so it is a strategic position of choice to simply not be vulnerable in the first place to such potential vectors of attack.
Attacks such as:
- Remotely downloading/stealing data & files from my/family computers.
- Spying on me/family, including physically, through computer sensors/peripherals.
- Planting evidence on, or committing crimes through my/family computers, etc.
The ME/PSP could be an excellent hardware-embedded backdoor platform for such attacks, where open/secure/trustworthy Firmware (coreboot) & OS (Qubes) would not stop it. I’d rather not find out the hard way, and just avoid the vulnerability entirely, if one can.
Also, it is a spirit of open computing freedom, where we are in control of our own machine and the integrity of the contents processed by the machine, as well as the control over its ability to phone home back to the mothership. Corruption of our computer security by humans that like to be overlords in a position to absolute control over all of us is just not right.
I personally support bad guys in the world being policed and removed from society, but absolutely disagree with spying on all of us good people in order to do it, and do not believe that such powerful military-industrial-complexes have purely good intentions. With the compromise of our computing platforms getting worse and worse in this new age of IOT & AI, holding on to what little prior free computing options we have, and also pushing for new breakthroughs is vitally important.
Cheers to freedom and an open civilian-controlled society!
Hi Thierry, hope @justmike80386’s recent firmware development success has peaked your interest again with the KGPE-D16 and family, after soured hopes of the past for the D16. Looks like the D16 is now in better shape than ever before. The recent pace of Mike’s progress is phenomenal. And all of the information on the 15h.org site is great. It looks like this could be a lasting and successful endeavor for years to come.
I see the KCMA-D8 firmware was just updated. And the various 4-CPU-socket SuperMicro H8QG* models look quite interesting.
fwiw and call me black pilled if you like, graphenos fails because its a google device, why trust anything intel… Or AMD. Maybe the only hope is RISCV? can software really bypass h/w backdoors? where do we begin? Not to mention the biggest names in this journey are MIA atm… And one of their last posts was a notebook and pen … No backdoors…
Sorry for the blackpill in this post, but we have all been focused on the ME and probably are missing much larger aspects to this puzzle. Ie the very nature of Intel, AMD, TOR and the MIC …
Ie a window into your life…
When you rip everything out of any device, the camera, mic, bluetooth, speakers, wifi, the ME, etc… whats left? In the end its hard not to see that it was perhaps built and intended as a spy-device from the get-go…
Thanks, I enjoy reading your black pilled perspective and largely agree.
Sounds intriguing. Not sure who this is referring to? Can you name this example?
Yes, newer AMD/Intel, with ME/PSP, and FSP closure, is known to be not open and therefore not trustworthy. Trustworthiness requires openness and security.
Manufacturer claims of any device/app/service being secure & private, with exception to being secure & private from the manufacturer themselves (and therefore government that controls/regulates/blackmails the manufacturer) is not something that is trustworthy and truly secure & private.
I don’t know, but automatically assume Google Pixel phones that run Graphene OS are not open and are blobbed too, so definitely not trustworthy.
I’m of two minds here, where 1) YES it seems many of such organizations are corrupted and are trying to backdoor everything to spy on everyone (certainly all you listed, but unaware of TOR corruption?), and 2) there is the technical reality of the hardware/firmware/software, where for example if Intel/AMD are ONLY backdoored with the ME/PSP then mitigating their specific backdoors could mean that Intel/AMD are then secure/trustworthy. One would have to know about and mitigate all backdoors though.
Back when ME/PSP was a hot topic a decade ago, I recall hearing hardware knowledgeable experts talking about how CPUs can also be backdoored through another more stealthy method. I forget what that method was, exactly. Something to do with millions/billions/or more(?) of some component in the CPU (maybe registers or transistors?) that could contain hidden corruptions that could enable a hidden backdoor that would be hard to check for and verify. Not sure exactly what it was, but something like that. Someone else might recall more specifically.
Using Pre-ME/Pre-PSP circa early 2010s and before, or later ME-Neutered, Intel/AMD hardware is an attempt to achieve such openness & trustworthiness. The question then is are such platforms secure, even if all intentional backdoors are mitigated? The Pre-PSP Fam15h (such as KGPE-D16) looks to be the best bet of this approach.
No, AFAIK, generally software can’t defeat hardware backdoors, if the hardware backdoor is privileged enough.
I understand, generally:
Hardware can rule over Firmware/OS/Apps/Data
Firmware can rule over OS/Apps/Data
OS can rule over Apps/Data
Apps can rule over Data
The only alternative speculative approach I can think of would be to create some scheme of confidential zero-knowledge processing where the CPU & RAM & Other Chips are not even given the plain text of what they are processing and can use some type of zero-knowledge processing of encrypted bits. Purely speculative.
We need at least the following Winning Combination:
Open Power (Raptor Talos II, Blackbird, etc) = Even More Open than x86, Not Affordable, Row Hammer Concerns(?), Seemingly Better Security than x86(?)
ARM = Affordable, Not Sure on Openness, Security, & Performance, as I haven’t looked in years
RISC-V = Affordable, Not Sure on Openness, Security, & Performance, as I haven’t looked in years
Something else?
Firmware options:
coreboot and its derivatives/distributions
Open Firmware native to a specific machine
Something else?
Operating System options:
Qubes OS
Genode/Sculpt OS
Something else?
I’m currently using Qubes OS, so naturally look to x86 Intel/AMD hardware for compatibility with Qubes OS, but am ultimately open to other alternatives that lead to a better Winning Combination.
But, Genode/Sculpt is supposed to be more secure & more minimal TCB than Qubes OS (although more advanced/opaque to use it seems) and appears to support other hardware platform options (like ARM & RISC-V) beyond x86 (note that Xen supports ARM but Qubes OS does not take advantage of Xen’s ARM compatibility). There has been past talk of Qubes OS being ported to and based on Genode in the past, so that is a future possibility.
Raptor Open Power systems are too expensive for my and most people’s circumstances and not supported by a trustworthy OS (neither Qubes or Genode, AFAIK). I could buy 1 or 2 10k USD Raptor machines, but that’s all. One could buy 10-30 AMD Fam15h machines for the same cost. When buying several machines, the cost of the Raptor systems is not affordable for most all budgets. Having a per-machine cost of under 1k would be good or at least under 2k per-machine.
In order to change the game, we likely need a white knight entrepreneur to come along who can throw 10+ Million or so at creating a business to start making (and selling at affordable prices) truly open/secure/trustworthy hardware that is compatible with trustworthy OSes which run Linux apps (such as Qubes or Genode). Such white knight hardware would be fully blobless at all levels, ideally with open schematics, and sold at relatively affordable per-machine prices. Companies like Raptor & Purism both seemingly had aspired to achieve such things, but have thus far failed, likely due to their owner’s financial inability to sustain losses in the millions for making a new market segment of product-offering like this.
Yes, unfortunately, it seems such surveillance capitalism is being pushed on the world to greater & greater levels over time, without any end to it.
I recently saw a new technology that is super scary and makes the ME/PSP look quite quaint and weak by comparison. The future of spying looks much darker, once you see this. I will likely make a separate post about this tech in coming weeks or so. It looks like truly diabolical levels of spying are coming deep within our computers & devices. All security systems people will likely have to deal with this as a pervasive threat. Will plan to follow up on this later.
