[bootstrappable] Re: diverse double-compilation

[Andrius Štikonas]

Ok, you make some fair points and I partially agree with that.

What I think you didn't realize, is that full source bootstrap does not need any software
on the system. You don't need guix or kernel either. You can start with
~200 byte "hex0" kernel and do kernel bootstrapping alongside userspace bootstrapping.
Of course there are still FW and HW (and on top of that you need a method to toggle
some initial data to memory) that you have to trust even in that situation. And this is all
already achieved on x86 and is even automated.

And yes, I agree that running it in different environments is good, but I was thinking of it
as running the whole thing on different machines, which I guess you can argue is DDC.

Andrius

2023 m. lapkričio 14 d., antradienis 02:24:05 GMT rašėte:
> Andrius Štikonas:
> > Diverse double-compilation kind of doesn't make sense (or is
> > superseeded) in the context of full source bootstrap.
> 
> The "full source" bootstraps still have various dependencies, so DDC
> still makes sense.
> 
> > DDC works in the following way: you start with a "trusted" compiler A
> > and "unknown" compiler B Then A->B->B and B->B should produce
> > identical hashes in the last stage, which would mean B is trusted.
> 
> I think you misunderstood the idea of DDC. You don't need a trusted
> compiler binary/system. Instead you take a set of different systems X1,
> X2, ... XN that ideally is as diverse as possible (in practice it
> depends how much effort you can afford and what's available). So ideally
> you have different compilers (binaries), OSs, hardware, binary
> dependencies (if any), etc.. Now you take your source S and build it on
> all systems. So you get a bunch of binaries X1(S), X2(S), ... XN(S). If
> they are identical you know that either everything is fine, or all
> systems produced the very same backdoor. The more diverse you choose the
> set of systems the less likely is the later.
> 
> (Obviously there are various assumptions here, most importantly: S needs
> to be reproducible even when built with different compilers! So most
> likely it will have a steps that builds itself again internally. You
> also need to assume that you are capable of trusting/reviewing S in the
> first place. Also we assume a trustable way for comparing inputs and
> outputs)
> 
> > What is a "trusted" compiler in the bootstrapping context?  We can
> > define "trusted" compiler to be the one that is bootstrapped from a
> > tiny binary seed, say compiler A was built from hex0, so it is
> > trusted.
> > 
> > If you start doing 1st DDC chain A->B, you have just bootstrapped B
> > and now B is automatically trusted, so there is no more need to do
> > another step and compare with just B->B.
> 
> Even starting from hex0 DDC makes sense since you still have various
> dependencies: the software running on the systems you ran the hex0-based
> bootstrap on, it's firmware and hardware.
> 
> But a hex0-based bootstrap has the advantage that you have much less
> requirements for a system to be usable for DDC, so it's easier to get a
> more diverse set.
> 
> Simon
>