Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bootstrappable Builds: How and Why

lwn.net

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Bootstrappable Builds: How and Why

#51

Post by siraben »

Rochus wrote: post #50
siraben wrote: post #46

Earlier quoted context omitted.

Specifically the expensive part is getting a C89 port of mrustc to compile rustc 1.90.0. mrustc needs C++ right now, bootstrapping via TCC by writing it in C89 would be the shorter chain.

Sounds pretty difficult (if not impossible, see cfront 4.0) to translate C++ code to C89. You have to keep track of all constructors and destructors and their progress along the body yourself, and I assume it must be fit for exceptions as well?

Yes, this isn't meant to be a complete port and I only started dipping into mrustc because the previous agents were going off the rails. I have mostly been throwing spare weekly quotas at this but deeper thought will be required to get an actual working Rust compiler in C. Rust is an enormously more complex language, so it might just be at the capability limit.

Re: Bootstrappable Builds: How and Why

#52

Post by Rochus »

siraben wrote: post #51
Rochus wrote: post #50

Earlier quoted context omitted.

Sounds pretty difficult (if not impossible, see cfront 4.0) to translate C++ code to C89. You have to keep track of all constructors and destructors and their progress along the body yourself, and I assume it must be fit for exceptions as well?

Yes, this isn't meant to be a complete port and I only started dipping into mrustc because the previous agents were going off the rails. I have mostly been throwing spare weekly quotas at this but deeper thought will be required to get an actual working Rust compiler in C. Rust is an enormously more complex language, so it might just be at the capability limit.

> Rust is an enormously more complex language

I have no doubt that a Rust compiler can be implemented in C. But it's a different project to write one in C from start than trying to migrate an existing C++14 based project to C. The former is likely "easier". An alternative approach could be to migrate the C++14 code back to C++98 and get rid of the exceptions, which makes it transpilable to C (using the cfront approach). Though the result might not be maintainable C, but still C.

EDIT: if you manage to migrate it back to a sufficiently moderate C++11 subset, or even C++98, you could use GCC 4.7.4 to compile it, which itself is written in C.

Re: Bootstrappable Builds: How and Why

#53

Post by siraben »

Rochus wrote: post #52
siraben wrote: post #51

Earlier quoted context omitted.

Yes, this isn't meant to be a complete port and I only started dipping into mrustc because the previous agents were going off the rails. I have mostly been throwing spare weekly quotas at this but deeper thought will be required to get an actual working Rust compiler in C. Rust is an enormously more complex language, so it might just be at the capability limit.

> Rust is an enormously more complex language I have no doubt that a Rust compiler can be implemented in C. But it's a different project to write one in C from start than trying to migrate an existing C++14 based project to C. The former is likely "easier". An alternative approach could be to migrate the C++14 code back to C++98 and get rid of the exceptions, which makes it transpilable to C (using the cfront approac…

Thanks, will look into this as another avenue!

Re: Bootstrappable Builds: How and Why

#54

Post by charcircuit »

Rochus wrote: post #47
charcircuit wrote: post #44

Earlier quoted context omitted.

>way out of a significant dependability problem This is not an actual problem. It is a made up problem that acts as honey attracting people to obsess over it.

Well, it might not be your actual problem. But there are always people who look a little further beyond the horizon.

It's not my problem. It's not anyone's problem. That's my point. It's also not something that's a little further beyond the horizon or the next weakest link that attackers may target next.

Re: Bootstrappable Builds: How and Why

#55

Post by charcircuit »

markjenkinswpg wrote: post #49
charcircuit wrote: post #14

So much time has been wasted by the open source community on pointless projects like this. >Reproducible builds allow people to "have more confidence that the binary you are using, which is actually executing on the computer, corresponds to the source code". The developer signing the build provides sufficient guarantees. Reproducible builds is another waste of time that the open source community has fallen for instea…

This is probably not a convincing argument, but I'll share it anyway. Think of bootstrapable builds as a hedge against tyranny. Is it likely that a future regime could come into being that would be backdooring FLOSS builds and undermining confidence in the entire ecosystem? Not at all likely, as this requires a purge of all the install/boot media already out there. Though after the passage of decades, the chain of cu…

This can be solved easier by having a known good Linux distribution that you make a million copies of. There is no need to start from absolute scratch if you are scared of open source code being wiped from the internet.

Re: Bootstrappable Builds: How and Why

#56

Post by lrvick »

charcircuit wrote: post #28
lrvick wrote: post #21

Earlier quoted context omitted.

> The developer signing the build provides sufficient guarantees. There are tons of documented cases of people resorting to physical attacks to obtain valuable cryptographic signing keys stored in full in one place. https://github.com/jlopp/physical-bitcoin-attacks I can only guess the people painting targets on their backs that big are woefully unaware of it, or living in deep survivors bias. Trusting control of the…

Reproducible builds and bootstrapping doesn't stop physical extortion of shipping a new compromised version either.

Sure it does, if you deterministically full source bootstrap, build, and sign the same image m-of-n places with different hardware owned by different people, all of whom only sign if everyone gets identical results, and this can be easily verified with remote attestation at runtime on a running server.

This is not a fantasy. This is exactly how https://caution.co works.

We can cryptographically attest with high confidence what code is running on a remote server at any given moment with these tactics. Entire classes of attacks are taken off the table with this approach, including BGP attacks if deployed properly.

Re: Bootstrappable Builds: How and Why

#57

Post by lrvick »

cyberclimb wrote: post #27
lrvick wrote: post #17

Earlier quoted context omitted.

The XZ attack was not in version control. It was on the human-built tar files published to Github Releases which no one reviews. Trust in a single person. Distros paranoid about supply chain attacks like stagex build directly from (ideally well reviewed) VCS snapshots for all modern software. Our defense-in-depth approach to supply chain security would have prevented the XZ attack because we never trusted the vulnera…

I thought the attack itself was version controlled via a tracked blob file used in a unit test. I believe the attack was performed by running the test suite (which modified the source code) and then compiling? If that's the case, then anyone that ran the tests prior to building from source would be vulnerable if my understanding is right

It was in the uploaded tar.gz file to the releases page. The vulnerable code bypassed code review, at least for those distros that trusted the human made source snapshots more than git which was a poor choice.

Re: Bootstrappable Builds: How and Why

#58

Post by tux3 »

moring wrote: post #48
tux3 wrote: post #38

Earlier quoted context omitted.

>as long as you run it on your own trusted hardware and verify the signature first. I think that depends how far you want to take the paranoia. In principle if you want that to be a secure signature that can't be forged, you're back to needing both hardware and software you trust to verify the signature. Hashing a large binary and verifying a signature on paper is wildly impractical. If someone prints the code and cl…

> because you're not going to be verifying that signature by hand At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that. > Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEF…

I was thinking an FPGA with an open toolchain might make a pretty solid hardware seed that can fairly easily be replicated, without needing your own fab or anything completely impractical. In theory the FPGA could still try to recognize and backdoor a bitstream right when you load it, but practically there's a whole bunch of different open-source cores that you could load on the FPGA, and it would be very hard to try to recognize and backdoor all those potential designs at the netlist level, or at least it would take a suspiciously large area, potentially visible as clearly more complicated than what should be needed on a microscope.

You could maybe distribute these verified boards that are just the FPGA and the verified CPU core + kernel + software seeds all stored on a basic NAND flash. But then instead of writing a lisp interpreter in machine code as your seed.. the seed would have to be an entire basic CPU that runs something like hex0, or like a basic lisp machine. You'd plug a keyboard into it and bootstrap the rest from there. But good luck with that, I'm not volunteering to try to make all of that work!

Plus there's still a small chance of a hardware backdoor somehow powerful enough to recognize any possible core you can load on it, or that the tools you use to even load a NAND flash or the NAND flash itself could be backdoored, so really we're just displacing the problem a bit further every time. But if you want to bootstrap everything from nothing, then you basically have to jumpstart all of computing electronics back up from nothing.

(And yeah, this is fun to think about!)

Re: Bootstrappable Builds: How and Why

#59

Post by charcircuit »

lrvick wrote: post #56
charcircuit wrote: post #28

Earlier quoted context omitted.

Reproducible builds and bootstrapping doesn't stop physical extortion of shipping a new compromised version either.

Sure it does, if you deterministically full source bootstrap, build, and sign the same image m-of-n places with different hardware owned by different people, all of whom only sign if everyone gets identical results, and this can be easily verified with remote attestation at runtime on a running server. This is not a fantasy. This is exactly how https://caution.co works. We can cryptographically attest with high confi…

You do not need bootstrapping or reproducibility for this. You can do the same thing just with a prebuilt OS and applications.

This is my point. Bootstrapping and reproducibility are made up problems that people think are important but are not actually needed.

Re: Bootstrappable Builds: How and Why

#60

Post by lrvick »

charcircuit wrote: post #59
lrvick wrote: post #56

Earlier quoted context omitted.

Sure it does, if you deterministically full source bootstrap, build, and sign the same image m-of-n places with different hardware owned by different people, all of whom only sign if everyone gets identical results, and this can be easily verified with remote attestation at runtime on a running server. This is not a fantasy. This is exactly how https://caution.co works. We can cryptographically attest with high confi…

You do not need bootstrapping or reproducibility for this. You can do the same thing just with a prebuilt OS and applications. This is my point. Bootstrapping and reproducibility are made up problems that people think are important but are not actually needed.

Without bootstrapping and reproducibility, you are trusting -one- person to build and sign for everyone else, and hoping their device was not compromised at build time. Single point of failure.

Without deterministic full source bootstrapped builds, you cannot verify a build someone else did was not tampered with at build time.

I did not say every user reproduces. In practice 2+ _maintainers_ reproduce and sign on behalf of all users, avoiding trust in any single computer or machine.

Post reply on HN