With only needing the Intel FSP, does that disable the Intel ME? And what other peripherals need closed firmware?
You also are not here:
https://www.coreboot.org/users.html
I say that because I have been in the market for a laptop, and I am looking for a free(dom) based laptop. I looked there and it led me down the path of a Purism laptop.
Have you also thought about adding some sort of hardware kill switches for Cameras/microphones/Radios?
I will get https://www.coreboot.org/users.html updated as soon as possible.
libgfxinit works even on Kaby Lake now.. but I see that you're using some ridiculously new 10th-Generation stuff for new laptops.
> HECI message early in the boot process, so there are no runtime ME components similar to using the HAP bit on older ME versions
Hm, I haven't heard of the HAP bit being gone?
Also, you can still remove extra ME modules, right?
libgfxinit support for Comet Lake is coming. The Intel GOP driver is a bit different than this, though. There is an Intel PEIM graphics driver that comes from the PSP, that provides a software-rendering framebuffer similar to what libgfxinit does. The Intel GOP driver provides some hardware acceleration, which is useful especially for HiDPI systems but not critical to device functionality.
The HAP bit does not have an effect since ME version 12. ME 12 was used on Coffee Lake systems, and ME 14 is used on Comet Lake systems. These support a different method of disablement using a HECI message, presumably to make dynamic disabling of the ME easier to do. Our firmware always sends this message, having the same effect as setting the HAP bit.
me_cleaner does not appear to function on version 14 of the ME. As soon as it does, we will also utilize me_cleaner to remove ME modules.
But why would I believe this? It seems you're selling snake oil. You can't really call it open firmware if there's still a lot of closed firmware in it.
The ME could certainly still be active, that is true, but with modern x86 platforms attempting to disable the ME or PSP using the documented method is the best that can be done.
A very large amount of the work the firmware does is done by open source code in either Coreboot, EDK2, or the System76 firmware applications. It is my opinion that this definitely does count as open firmware.
You should look at the libreboot project and read their blurb on why they do not support post-2013 processors.
Trying to sell the devices described as open is harmful to the term. They're not. Perhaps the only devices which are at this time are the IBM POWER processors and the Raptor CS motherboards, discounting any silicon backdoors, and in the case of the Raptor motherboard, the ASpeed BMC.
If you're in the market for some slow CPU, maybe. For high performance stuff the creator will likely have to license some function blocks that come with strings attached.
I'd love to see a fully open RISC-V core with a DDR4 interface (and USB2/3 for all kinds of interfaces), but somehow I just don't see that happening before DDR4 is all but obsolete: those interfaces aren't trivial to build (so that they work with all kinds of stuff) and few folks have the equipment to test their Verilog (or whatever) that would implement these high speed controllers against real devices.
I do care that the in-memory key can not be read and transmitted without my OS' knowledge.
I have other computers for games and development and servers, and the NSA can have my steam password and already have my work email.
Of course, ME has easier time doing that. But any ROM you can't inspect, any binary blob you load can do that.
I suppose that if you want this level of impenetrability, you have to go with everything custom. Could your memory controller scheme against you and alter RAM contents when a backdoor pattern is encountered? Do you trust IBM to not put a backdoor or a kill switch in your POWER9?
Implement your CPU, memory, bus, and disk controllers, NIC logic, etc, in FPGA. Build your own RAM with controllers you program, don't trust DIMM manufacturers. Write your own or adopt open booting software, same with firmware for the peripheral devices.
You'll get a very high security computer where a backdoor has basically nowhere to hide.
Alas, it won't fit the restrictions of a laptop.
I can implement IEEE1275-1994 as fully closed sourced code and call it open firmware.
> if there's still a lot of closed firmware in it.
Downthread you mention "With nonCPU blobs there is (usually) a memory boundary", which I'll take as the boundary you made for yourself in these matters.
With this boundary, the amount of "closed" firmware doesn't matter. The right 8 bytes at the right place and time are enough. Guess what:
> But why would I believe this? It seems you're selling snake oil.
The initial bootstrap is basically always implemented in a boot ROM (whether you see it or not) and it could decide to implement a backdoor unless some conditions are met.
According to your criterion all computing out there more modern than Z80 or 65816 era stuff is insufficient.
Hardly. You can call it Open Firmware(TM), not open firmware.
Which is in any case irrelevant. Open Firmware != open firmware.
Given that there's apparently no protection at all, I see no reason why I'd have to adhere to your wish to use 1275's way of writing O and F in upper case. So yes, I _can_ call it open firmware.
Open Firmware != open firmware.
let's shorten the other thread, since you just reiterate the same claim all the time without backing it up: I reject your prescriptivism just like I reject snagglegaggle's.
Initial bootstrap can be ROM, can be closed, but need not be. Stop compromising and accepting the status quo. The IBM POWER systems by Raptor have open firmware at every level. Is the CPU design open? Not entirely, but it is overall better, and I'm not trying to mislead people about it like the sales rep in this thread.
Your firewire example is disingenious, and no, I would disagree that it is open. Charlatans like System76 abuse the terms to sell their products taking advantage of the goodwill of those who do not know better.
That would be https://review.coreboot.org/c/homepage/+/35957
Even if a key were to be stolen from Intel it would then be illegal to use in all Western nations. The ME is off limits to everyone other than Intel and its partners, enforced by both the hardware signatures and some of the most heavily enforced (in terms of consequences) legislation on the face of the planet.
Of course that won't stop malware authors, who couldn't care less about replacing the ME firmware to make it secure, but do care very much about the fact that they can hack into the stock, signed Intel ME firmware, then install their malware in a nearly impossible to detect position.