well, government officials like to hack hardware. Typically a spy etc connecting to your motherboardchip with a EEPROM reader, changing your bios so that it connects with vnc connection to their server b4 the operating system even starts to run. Doesnt matter what operating system you run, your computer is their computer allways connected to the server when you are online. If you have wifi adapter they can connect even if your not connected to internet as long as they have signal. This is why Qubes is not the ideal solutions because it is only a operating system. We need open source hardware, fully documented, so that ppl are able to detect such hacking. Who knows, maybe computers come with backdoors included, such as the intel ME or gpu flash memory etc. I think you can detect if your motherboardchip is hacked if you use such EEPROM reader and compare the content with the content from the file downloaded from the motherboard website. The file used to update your BIOS. I have such virus on my computer. Does anyone know how to remove it? Would updating bios using EEPROM reader solve my problems? I tried updating the BIOS from usb, but it didnt work. My bios seems to be updated to the newest version when i go to bios menu, but i still have vnc connection on startup. So donations to make a computer without Intel ME or amd PSP would not be sufficient for anyone without opensource hardware, fully documented. Everything can be explained simple. If u cant explain it simple you dont understand it, albert einstein
Well the raptor power9 computers are open hardware. How do you know you have such vnc connection though? your alternative is a system running coreboot i suppose.
It is not open source if they can sell it for 2000 dollars. The parts on the motherboard are probably not worth more then 20 dollars, including the cpu. Its all overpriced junk. The cpu is not open source. Someone would make a ripoff and sell it cheaper. It is not well documented and explained. Also the operating systems such as qubes and fedora. They claim to be open source, but you cannot decompile the installer to check what you actually install. On the power 9, can you actually read the chips on the motherboard and understand what the code is doing? Because when u read the data on the chips on a regualar motherboard it is not possible to tell what the stuff do, u just see a bunch of crap, apears to be random stuff. I bet if i read the motherboard chips on my motherboard i would be able to find inequality between the file that im supposed to upload to my chip, from the motherboard website, and what is actually on the chip. But i dont know if it is enough to check the motherboard chip (Bios chip). I dont know how the motherboard work in detail.
You ask for easy to understand information and yet talk about firmware.
We are not talking about a basic toaster here, where schematics alone may be complex to understand with resistors and electric impedance. And yet again, most people will replace said basic toaster instead of repairing it.
I think there is some confusion here. If for 2000 dollars we are talking here about the Talos II board only (without CPU, which is made by IBM and expensive), which is RYF certified, and when you buy it, it comes with source code and schematics, where the motherboard is Open Hardware and the CPU documentation and schematics can be found over OpenPower, the fact that nobody else is making such boards (2018) is interesting. And yet again, the answer to that is yet again not so simple. The question here being: who else the IBM could do Power9 CPUs fitting the same socket. And the answer there would be: anybody having enough money to do a foundry for such CPUs. Then the other underlying question is: who would create a clone (ethics? moral?) from the Talos II, for CPUs that are from 2018 with v2 (spectre resistant) from 2019? The security/privacy/user owneable hardware enthusiasts is not such a big crowd compared to Intel and then AMD ready/cheap to buy hardware. Who would jump in that adventure with the challenge of reducing the costs in the current silicon supply-change-problem-era we are now since Covid. I do not know, but those are the real questions, where even the really big players are suffering to produce and supply-chain their components. the costs are maybe a bit more hidden, less models produced and less seen, but the reality is still there. The real question is who can produce new motherboard, firmware and software for new architectures without the board itself costing 2000$. Already thriving big companies diversifying their income, maybe. But those, historically, will prefer AMI UEFI BIOSes and Intel CSME nowadays for later on explained reasons. Cheaper in bulk.
The CPU IS open source. The ISA is OpenISA. The motherboard is open source. So if I understand correctly, the question is why there is no more competition there? Because Power10. And because Power10 is not so Open ISA anymore, for multiple reasons I think I already addressed here. For more specifics I encourage you to read Talospace which will do a way better job then myself digging with you this rabbit hole.
But my understanding of the situation is: inflation (costs have exploded). And consequently, lack of competition as well.
ā¦ This is the other way around. You can build from source if you want. The installer is deploying packages compiled and packaged into the ISO image, where templates are also built from Qubes OS builder, which is a project on its own: Qubes builder | Qubes OS and where moving away of Fedora is a subject having years of discussions happening around, where moving out of it would mean having Qubes small team maintain for yet not open hardware machines that require drivers and firmwares to be present, and loadable, at the installer to give you a graphical installer. Otherwise how would you install it on not so open hardware today? I feel you are going a bit in all directions here. Fedora is not considered Free Software (approved) by the FSF because Fedora is linking too easily to closed source software in their repositories. For them to approve an OS (such as Trisquel) the OS itself needs to run on open hardware, or the user needs to hack around to have himself go on the internet and go on youtube or what else. The problem here is to have things that work out of the box for most users. Here the FSF is inconsequent. Try to use any other RYF hardware then the KGPE-D16 or Talos II to go online today and have conferences or remote meetings or attend online classes with a X200 today. Good luck. Where it is possible to do those things on a BlackBird (not RYF certified as of today but I do not see why not, question should be asked to Raptor) where the CPU is powerful enough to render videos out of the CPU alone without hardware acceleration.
This is yet again another rabbit hole. To be able to properly accelerate things we need today, we have chips and closed source components burned into chips with patents and royalties being prepaid at the time of buying. The reason those Acer/Asus/Dell/Whoever other big players are able to compete with each other is basically because they buy in volume the same components most of them reuse in each of their new generations of products. The reason owner controlled/open hardware is more expensive is because there is not such market and not so much demand and that they do not make 100 000 000 units in advance when its time to create a motherboard. They all use the same CPU. And as opposed to end users ordering a non-soldered and replaceable CPU at high price when the device is new, those gigantic makers are having price on volume. So they are able to do a profit margin on the product. And yet again, there is not really any hardware maker, last time I check, which is able to make more then 30% markup on hardware, unless someone else land money, and then it is another story altogether. Reverse the question around: how can you make hardware less then 2000$ and still make profit if you are the one making the design, doing the firmware, the R&D, the sells, support etc? Pay employees etc.
Even on the used maketspace, myself, making profit is not so easy after all the expenses. People seem to believe that things are so easy and should be so cheap. But until you do it yourself; you realize that nothing is so simple and most importantly, nothing is that cheap.
Well, as far as I know, you cannot read what the CPU has printed on die. But there is no microcode update there. As for the firmware, as said as well previously, you can build everything from source, and have the BMC test run your new firmware prior of flashing it, yes. You can now compile coreboot+skiboot+heads, and there is now a PoC (requiring TPM add-on, I know, TPM is closed source again) or choose Kestrel (1500$) to replace BMC which is evolving as a hardware root of trust on an FPGA. But to answer your question: yes.
The ending of that last block repeats how I started my reply here. It is complicated to understand how things work, even for experts. When things are too high level, it looks like marketing speech and unicorn poop. When things are too dense and complex, it looks like dark magic. The thing you are talking about here is taken on the wrong side. People working on open source firmware are working toward this goal the other way around. And this is called reproducible builds (where Qubes as well is going that way with debian builds and articles they produced in the wins they had going in that direction). The principle of reproducible builds is that the same source code should produce the same output all the time. This requires patches to make sure nothing from the host is leaked into the builds, or the use of a reproducible build stack (think/search Guix/Nix and others) where everything that is installed is in known state AND can also be built from source. The question there is what is the minimal needed to bootstrap everything, which Guix has made magistral advancements in the past years. When you have reproducible buildstack (which can be audited, and/or rebuilt to obtain the same hashes) then you can expect that what you will build will have the same hashes (measurements) as well.
The same principles are applied to coreboot, which when you build it, requires you to build first its build stack for a specific coreboot version, which will be used to compile your ROM (firmware). The same principle is expected of other subprojects, like Heads, but things drifted in the past, where some funding was obtained to reuse Guix/Nix as a build stack to produce Docker images/have the buildstack deployed on top of a Qubes linux template/Standalone to be able to produce the same ROM/Firmware for a git commit (a change in open source).
When you have that, for any software (a firmware is a packaged software that runs on hardware, and should be considered the same), if you have a hash that is the same as a Continuous Integration (CI) system produced, and a community is rich enough (n open source, enough eyes looking at the same stuff) and/or multiple CIs building the same stuff on top of different OSes with a reproducible build stack installed on top of it, they you should be able to ahave reasonable trust/verifiable trust into the binary (ROM) you are about to flash (on reasonably secure hardware as well).
Then, what can be reasonably trusted seems to be your question.
When it comes to pre-boot environment, the idea there is to have at least some hardware security anchor to be able to provide measurements soon enough to report on the current state of the firmware. The ideal here would be to have such anchor in the processor, but as you know and complain about, those anchors would not be trustable (Johanna definition of trust here). This is what TXT and Bootguard is promising, having the CPU put in a trustable state on reset vector (first thing the host CPU doesā¦ After ME/CSME, of course) to measure the bootblock or whatever is under IBB (talking coreboot/TCB here). See, it gets complicated.
Some reference, maybe? Anyway, the point here is that without a hardware root of trust (it could be that your EEPROM is locking in RO the regions needed to measure the nexts as well), what do you trust? We know that current attacks are targeting the firmware nowadays. So the idea here is to at least know that something changed there. This is called Measured Boot. And this can be implemented in a number of different ways, but most of those ways requires an external source for measurements, which needs to be launched from a trusted place.
There are not millions of ways to do this. The firmware implementation needs to be able to talk really early to that hardware for measurements. Ideally that hardware root of trust should be tusted to not change. And this is where another rabbit hole starts. As of today, newer computers are now implementing Pluton, made by Microsoft/Amd/Intel partnership. If before, Intel ME/CSME was living on an external CPU to provide helpers to do that job, and where Ivy bridge is too old to implement TXT with IBB protection and where Haswell is the last supported coreboot model without requiring Intel FSP (after that, coreboot/osboot is not open source at all anymore), the IBB (bootblock, ME region, other stuff user wants to make sure doesnāt change) can be attested by the CPU measuring the EEPROM with an external source of measurement (normally closed source TPM). The last model Iām aware doing that is the t440p, but there is currently no open source implementation permitting to do that, where the blobs (proprietary code) required to do that (ACM blobs) need to be extracted, and the juridic space is unknown on if those blobs are redistributable or not. In doubt, they arenāt.
But to answer the simplest possible your question:
libreboot is not targeted at security. There is no microcode update, the machine is slow and old, and kernel mitigations will slow down the machine even more. This is unpractical. Plus, the machine you would run under libreboot is so old, by definition, that it would support Qubes either by lack of hardware isolation feature (it supports vt-d1 not vt-d2, see above and elsewhere on this forum, I already replied to similar questions). Where virtualization (vt-x) requires microcode updates. Ok, lets say you decide to go there still. Then how would you know that your firmware was not modified? There is no TPM there either, too old. So no way of using Heads to add some measurements from the firmware even if there is no hardware root of trust (Nothing external permits to measure anything, and the initial measurement would not be protected). The X200 and others are machines that are aimed at users who put user own-ability on top of security. Iām not sure you would write on this blog if this was your case.
osboot: yes, why not. But how do you verify that your firmware was not modified? Then I would question: why not Heads then?
Or again, if you decide to measure but not trust (read: decide to go for more recent hardware full of blobs, but you want tot make sure that those blobs do not change over time) the project to read into is safeboot, which is on top of UEFI (I do not trust UEFI and vendors, but that is for everyone to dig and understand, I guess)
It is unfortunately not so simple, even if you understand. There is no simple analogy here. If you think OS is complex and think you need to decompile stuff instead of compiling it and obtaining the same result, what is happening in CPUs and architectures is a mess on top of mess since the beginning of computing times, also for compatibility reasons and to have similar architectures, and competition between the big ones that made history.
On my side, what Iāve learned is that what I once thought simple was way more complex the initially thought. Then I can vulgarize it, and then when I look at it again later on, most of the time it changed again. So my question to you on the last point would be: explaining to which audience? Because understanding low level stuff is one thing, explaining it simply is another (You can take free courses if you want, btw: https://opensecuritytraining.info/
Anyway, knowing to explain, to me, is a complementary skillset to understanding. And both are needed to teach. If you want to study those things, free to you, but you will realize that its hundreds of hours of studying (I havenāt done them all myself) and I doubt someone will do a better job then what is happening at https://opensecuritytraining.info/ and explains the whys and how of security problems with current architectures we can by for cheap and older ones.
Laso, as I posted elsewhere: this timeline should give you envies of staying away of UEFI (the firmware you get normally on computers you can buy off the shelves). It should also make you want to have more coreboot enabled systems. But then you will understand that those systems are rarer and rarer, and that they all depend on Intel FSP (Firmware Support Package) for newer supported platforms. And then will understand that AMD under coreboot is the same with AGESA. And that ARM is no better. And that Risc-V is not so free either on current implementationsā¦
So yeah. OpenPower is what we have.
- Coreboot port documentation for Talos II over here: GitHub - 3mdeb/openpower-coreboot-docs: Documentation related to POWER9 coreboot porting effort
- Higher level documentation here: https://docs.dasharo.com/variants/talos_2/installation-manual/#testing-firmware-images-without-flashingtaloss
Hope it was explained well enough, even though not simple to explain. Hopefully helpful to some.
I appreciate the write up. The information and links help. From what it sounds to me, it seems like power9 is the only hardware I could trust then at the current moment for a desktop with some computing powerā¦ correct me if iām wrong in that regard. Currently posting from a t440p but, I can assure from experience that most modern hardware has LE/gov backdoors in place.
This is not an easy answer to give and prior answers in this thread gave links as well to explain what are your choices.
I pointed to t440p because I try to simplify choices for you. The T440p is the oldest gen supporting TXT with IBB possible to be locked down as a root of trust, but not yet done. Its the last version of ME that can be neutered. But also the first coreboot port (after Ivy bridge) ehich requires a blob (closed source binary) required to do ram initialization, while not requiring FSP. So theoritically, it could be supported under Heads with measured boot and ACM blobs to have hardware root of trust under SINIT (a blob providing security services to have the CPU talk to the TPM prior of running anything from the firmware outside of this blob), while IBB regiom (bootblock, ACM SINIT and ACM BIOS blobs can be extracted from downloaded Lenovo website).
The firmware could be locked from the EEPROM (spi chips) to require external flashing to overwrite IBB region. This would guarantee that IBB cannot change unless external reflash, TPM would have PCR0 measurement made directly from the CPU on SINIT( secure init). And Heads would then include PCR0 measurement intonits sealing/unsealing, making the t440p the first candidate having neutered ME, no FSP and enabled TXT. Basically, this is trusting Intel to do the right thing when you press the power button to have Qubes OS today, while adding two things in firmware as opposed to Ivy bridge (x230): ram init blob amd ACM bios/sinit to have better prr-boot security. Otherwise on Ivybridge, best to be done is to platform lock EEPROM (that was bypassed in the past) or to write protect the bootblock, which would require external reflashing for firmware upgrade at the profit of having native ram initialization. On newer x86 hardware everything initializing hardware is closed source where coreboot tries to fix after the fact what it can.
For Power, its different. But forget about qubes now (no xen) and software availability is not as wide as for x86 today. Power is better for sure, but it is not as widely used as x86 with all its consequences for the moment.
Like I said, not so simple. 
Sounds simple to me, either use power and compile your own software or use some old laptops lol. Iāve actually never used Qubes. I currently just use openSUSE but have been looking at some BSD distros. thanks for the clarifications and details on all the issues and alternatives though.
Half a year ago i was shopping a new office chair and i found out that it is about 2 000 000 different types of officechairs to choose from, from 800 000 different brands. All we need is one officechair company called the officechaircompany and they make three types of office chairs. One normal and one advanced and one experimental. The same goes for sofa, bed computers etc. The way the economy works today you cannot achieve open source computers with documentation. I stand by my statement, everything is simple to explain if u understand it properly. Education is fraud and economy is fraud. Smart ppl are not motivateted to do anything
@Insurgo thanks for you interesting writes ups. Do you happen to know if the Power9 port of Xen can support or be used as a base to also support a cheaper Power CPU like NXP T2080 ? This would be particularly interesting since there is a project to build a laptop with NXP T2080 CPU.