Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    Oreboot has been in development for a number of months now and while at first may have sounded like a novelty downstream of Coreboot is now proving its usefulness and taking shape...

    http://www.phoronix.com/scan.php?pag...ust-Fully-Open

  • oiaohm
    replied
    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.




    Leave a comment:


  • jjkk
    replied
    Originally posted by oiaohm View Post

    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.

    Originally posted by oiaohm View Post

    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.

    Originally posted by oiaohm View Post

    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".

    Leave a comment:


  • ssokolow
    replied
    Originally posted by duby229 View Post

    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.)
    Last edited by ssokolow; 09-05-2019, 12:35 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by bug77 View Post

    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....

    Leave a comment:


  • oiaohm
    replied
    Originally posted by jjkk View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by jjkk View Post
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.

    Originally posted by jjkk View Post
    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.

    Leave a comment:


  • jjkk
    replied
    Originally posted by starshipeleven View Post
    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.

    Originally posted by oiaohm View Post

    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.

    Originally posted by ssokolow View Post

    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by DoMiNeLa10 View Post
    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

    Leave a comment:

Working...
X