jackpot51

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.

I will get https://www.coreboot.org/users.html updated as soon as possible.

Let me know if you have any questions. The source for this can be found here:

https://github.com/system76/firmware-open

There are instructions there for building and testing the firmware in QEMU, you do not need to have our hardware to try it out.

There are a couple known security issues in the kernel regarding memory management.

One is that memory is granted in pages, so buffers passed to a scheme are over-mapped for the process handling it. You have to be root to handle a scheme, so it was not a high severity issue. The fix will be to copy to tail and end pages allocated to each context, so that it will not have access to extra data.

Another is that grants can be dropped by the owning process while in use by another process. This can lead to the re-allocation of said grants in the owning process, making memory accessible to the other users of the grant. More kernel work is needed to prevent schemes from leaking data in this manner.

That is the one you need for a VM.

In order to make this easy, ELF loading is part of the kernel. Otherwise, the ELF loader would have to be loaded somehow. How does QNX solve this issue? I could see there being a simpler executable format, or maybe the loader could do what the kernel does and modify its own paging tables.

With regards to the book, it was outlined by a contributor who is no longer part of the project, so it is likely to be restructured when there is time, and the sections may change.

There are drivers for what are considered to be critical features for any userspace inside the kernel. This mainly means the interrupt controller, but has included a serial console for kernel debugging. This will be an optional component in the future.

Imagine you want to revert firmware for legitimate reasons. As the originator of the firmware, you could revert the source code and have a new build spawn that produces a valid artifact. With our system and with the typical system, this is possible.

Now imagine you are an attacker who wants to release an older firmware version, which potentially contains a vulnerability. You have access to the publishing system, but not the build system or signing key. With our system this is impossible, as consumers will not allow moving backwards to an older build. With the typical system, any signed firmware blob can be released at any time, meaning an older version can be made available without having to rebuild.

Our build system utilizes a firmware signing hardware device connected to the build server over serial with a strict protocol to ensure that leaking the key is not possible, even if the build server is compromised. In addition, the key is destroyed if this firmware signing device loses power (it does have a battery backup, but it disconnects if the case is opened), and we must deploy a new key in that event through software upgrades on client machines.

Redox is not ready for production and I am not hesitant to admit so.

Those things may not all be perfect, but they do make a big difference.

The only alternative is to reverse engineer the SPI flashing method. We have switched to using FPT, the Intel Flash Programming tool, on new models. This means that we need to reverse engineer the SPI update method, which is something the flashrom project has had success in doing for older Intel chipsets.