Oreboot Is Taking Shape As Rust'ed, Purely Open-Source Focused Coreboot

[jjkk]

You are not doing secure systems. Something like a Sel4 build for a military drone every single bit of build code/binary used has to be audited to prevent tampering.

I do not. Just a hobby project. But should that stop me from striving.

7 build and audit that is 3 weeks of processing time on large systems gone. 70 build would basically be never able to complete because by the time you complete you are out of date and have to start again.

The less moving parts the better. Who would disagree. My point is if the number of builds can not be as low as I like, I still would prefer the build chain in clean and deterministic steps. So that I did not need to play with bare metal every time something changes in compiler or linker. So doing it once and then run things as translation or in VM and compare binaries is fine. Reproducible builds, right.

Do not quite understand the start over part. If the bootstrap process is established as audited, then you need to review only incremental changes to see that they do not do something unexpected.

http://wiki.c2.com/?TheKenThompsonHack
This was written in 1984.
Yes compilers that infect though the complete build process have appeared at different times. The longer the clean boot strap path comes the more risk that a infected compiler will be used and harder to find due to more code to hide in.

This is also why debian doing reproducible builds in the hope that multi parties don't end up with compilers all infected the same way but still this is still open to everyone using the same infected compiler somewhere in the process so all the results in fact matching up.

There should always be work to reduce clean boot strapping volume of code required and you really don't want to see clean boot strapping taking more 5 builds to make a compiler if possible and absolutely not more than 10. Yes 10 the audit process is already getting insanely hard.

Nice and old tale. Not paranoid enough to believe it is realistic today though.

In general, to implement such thing equals to implement an AI on its own. In point of fact, privileged programs like login or sudo are few and one can disassemble them on several platforms using several tools both free and commercial. These programs are simple enough to make sure they are not infected. Comparing to 80's today's disassemblers/decompilers can do miracles.

Back to Rust concerns. The complexity of reproducing GCC has grown up in natural way and there are no any artificial barriers to bootstrap it. Tools like cc/as/ld/make are all plain and standalone. While Rust "modern" approach does not anticipate that at all. Even if one manages to bootstrap compiler itself, it depends on Cargo indivisibly which may or may not download something from the web. And when you manage to cache these dependencies offline it is an unmanageable self-contained mess. It does not implicate any manageable and deterministic build process.

Their "it just works" and "trust us, we know better" approach is a direct opposite of their so bold claims like "reliable", "safe", ahem.. "truly open".

[oiaohm]

The less moving parts the better. Who would disagree. My point is if the number of builds can not be as low as I like, I still would prefer the build chain in clean and deterministic steps. So that I did not need to play with bare metal every time something changes in compiler or linker. So doing it once and then run things as translation or in VM and compare binaries is fine. Reproducible builds, right.

This is going on a theory that is not 100 percent true.

Do not quite understand the start over part. If the bootstrap process is established as audited, then you need to review only incremental changes to see that they do not do something unexpected.

The problem here is an Audit is never perfect. As time go on new methods of auditing get developed that can defect faults that you could not detect before.

So the idea that you only need to review the incremental changes is wrong. You need to repeatably review the complete code base with all new auditing methods for flaws. So the reality is the boot strapping process is never ending in high security.

Nice and old tale. Not paranoid enough to believe it is realistic today though.

https://en.wikipedia.org/wiki/XcodeGhost

The Ken Thompson Hack was written about in 1984 but it has happened a few times. XcodeGhost was one of the largest cases and that is only 2015 yes if you built binary with two infected copies of Xcode they were reproducible builds. So reproducible infected so was in fact proven in 2015 as a real possibility flaw in reproducible builds not just a theory one.

In general, to implement such thing equals to implement an AI on its own. In point of fact, privileged programs like login or sudo are few and one can disassemble them on several platforms using several tools both free and commercial. These programs are simple enough to make sure they are not infected. Comparing to 80's today's disassemblers/decompilers can do miracles.

Sel4 developers covers doing that. https://entropy2018.sciencesconf.org/data/myreen.pdf say hello to time consuming.

While Rust "modern" approach does not anticipate that at all. Even if one manages to bootstrap compiler itself, it depends on Cargo indivisibly which may or may not download something from the web. And when you manage to cache these dependencies offline it is an unmanageable self-contained mess. It does not implicate any manageable and deterministic build process.

Their "it just works" and "trust us, we know better" approach is a direct opposite of their so bold claims like "reliable", "safe", ahem.. "truly open".

I agree this is a problem. This kind of build pattern is perfect for the "The Ken Thompson Hack". Someone infects a snapshot on the server and all down stream builds can be reproducible infected. Rust does not have the sel4 disassemble and compare to model "don't trust compiler route" or a correct audit -able bootstrap at this stage.

Really jjkk you are most likely exactly like the rust developers on dismissing "The Ken Thompson Hack" concept of 1984. If you don't learn from history you are doomed to repeat it. I cannot see anything in the rust build process that provides a true counter to "The Ken Thompson Hack" in fact it looks like a large nice open field to go after for broad attack access. Remember infected rust compiler could get you into firefox.....


Lot of what what I think when someone say modern approach normally means to me this person has not read history and learnt from it. I far prefer a historically sound approach over a modern approach.