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

[Guest]

I'm not too fond of this idea, as it will lead to duplicated effort. Plenty of code in Coreboot is written in Ada, so I assume little of it is written in C.

Libreboot exists, and targets truly free setups. It removes all blobs and platforms that can't be supported with only free software, and provides scripts to ease setting everything up, along with configs that are quite useful even when dealing with upstream Coreboot. I know because I used the module list to set up my GRUB2 payload.

[aksdb]

I wonder why not Roreboot then?

Sounds awful

oreful?

[starshipeleven]

oreful?

rustful.

[starshipeleven]

I'm not too fond of this idea, as it will lead to duplicated effort. Plenty of code in Coreboot is written in Ada, so I assume little of it is written in C.

Where you get the impression that any significant part of code in Coreboot is written in Ada?
Github says there are literally 2 orders of magnitude more C files than Ada files https://github.com/coreboot/coreboot/search?l=C

[jjkk]

Yeah, both GCC and LLVM can be built from source without requiring a binary compiler, because somehow you can compile them by looking at them in a certain way.

Are you fucking serious?

I build them with my trusted build of GCC.
I am.

https://bootstrappable.org/projects/mes.html Many project maintain the tutorial howto bootstrap current gcc from non C++ compiler

Clean bootstrapping current gcc has come a pain in the ass its tinyc to GCC 2.95.0 to gcc 4.7 then to current. Yes this bootstrap path is required when you have a clean platform with no binaries.

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

Its not like it really was impossible to write the core of the compiler in C++ yet still boot strap with C just no one really wanted to.

ssokolow gcc boot strapping build the xgcc is built then the xgcc rebuild the code again. So its currently 7 builds to clean boot strap gcc due to the change to c++.

Yes a C++ to C converter + tcc could possible allow building the current xgcc so making 3 builds to boot strap.

Really needing to clean bootstrap with audited code current gcc is a bastard.

Thank you. I am aware of how to bootstrap GCC. It actually takes more than 7 builds and I would not care if it was 70 or 700. It is all automated in my build system.

For the same reason that GCC doesn't provide a tutorial on how to bootstrap GCC from a non-C++ compiler... or, as far as a quick google shows, from a non-GCC C++ compiler. (And, yes, GCC stopped being pure C a few years ago as was mentioned here on Phoronix.)

Bootstrapping is not intended as an official method to install it, any more than expecting building GCC with some random compiler like TCC to be an official supported method of install. If you want to bootstrap a self-hosting compiler, there's an implicit expectation that you're skilled enough to write your own instructions as you go.

mrustc's purpose is to prove that the official binaries are safe by producing bit-for-bit identical replicas through a laborious but much more auditable process.

If it's the "running arbitrary shell scripts" part you have a problem with, that's what the Other Installation Methods page is for. (Though you won't see me arguing if you complain that the current incarnation of the site is an iOS-ishly confusing "determined to be simpler than is actually possible" mess.)

Of course I have tried all the "other" methods they suggest. Once again it looks like you have no idea what are you talking about. Their other method is to download and run the blob manually, instead of curl | sh. Not a tiny bit different.

What is that bit-for-bit proof and audit you are mentioning? Even if it was possible years ago it is hard to tell because ATM bootstrapping from rustc is broken.

Moreover to this day the language itself does not have a formal proof of correctness if you even know what that means.

[ssokolow]

Of course I have tried all the "other" methods they suggest. Once again it looks like you have no idea what are you talking about. Their other method is to download and run the blob manually, instead of curl | sh. Not a tiny bit different.

Note that I qualified that link with "If it's the "running arbitrary shell scripts" part you have a problem with" because you seemed to be drawing a lot of attention to the | sh-based recommended installation procedure.

What is that bit-for-bit proof and audit you are mentioning? Even if it was possible years ago it is hard to tell because ATM bootstrapping from rustc is broken.

You bootstrap an older version of rustc that mrustc can handle, then use that to build newer rustc versions, and verify that, using a C++ compiler that has been verified through diverse double compiling and sources that are known to be free of backdoors, you get a compiled version of rustc that has the same file hashes as the self-hosted builds.

They documented the process that worked for them in the form of the TestRustcBootstrap.sh script in the mrustc repo.

On December 11th, 2018, that "older version that mrustc can handle" was rustc 1.19.0.

Currently, 1.20.0 appears to be the version specified in TestRustcBootstrap.sh.

Moreover to this day the language itself does not have a formal proof of correctness if you even know what that means.

I actually do. Given that you seem fine with GCC, please provide me with a link to either the C language's formal proof of correctness or, more usefully, GCC's formal proof of correctness. Google is failing me on both of those.

Efforts are being made to incrementally verify Rust. See, for example, the RustBelt project.

[starshipeleven]

I build them with my trusted build of GCC.

That was built with?

Because I'm pretty sure you had to compile your "trusted build of GCC" with something that was not trusted at some point in time.

That's how compilers work. You can't compile a compiler if you don't have a compiler. Catch-22

I am.

Lol no you are not.

[oiaohm]

Thank you. I am aware of how to bootstrap GCC. It actually takes more than 7 builds and I would not care if it was 70 or 700. It is all automated in my build system.

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.

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.

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.

[duby229]

Not always. When copper "rusts", you leave that in place because it protects what's underneath
It does nothing to convey the whole thing is built around safety, I'll give you that.

My only critique of this opinion is that copper doesn't rust, it gets a patina. Patina is a type of calx, just like rust is a type of calx, again why Calx would have been a better name....

[ssokolow]

My only critique of this opinion is that copper doesn't rust, it gets a patina. Patina is a type of calx, just like rust is a type of calx, again why Calx would have been a better name....

Except that, from what Graydon Hoare remembers, he named it after the fungi:

<graydon> I think I named it after fungi. rusts are amazing creatures.
<graydon> Five-lifecycle-phase heteroecious parasites. I mean, that's just _crazy_.
<graydon> talk about over-engineered for survival

(Sort of like how, despite the icon, the Python programming language is actually named as a tribute to Monty Python.)