How to reduce our vulnerability from self-hosted compilers

How to reduce our vulnerability from self-hosted compilers

[Mark H Weaver]

We are starting to add more self-hosted compilers, where our build
recipes are downloading pre-compiled binaries from upstream.  I'd like
to propose a policy for dealing with this in such a way that protects us
as much as possible from upstream security breaches.

So far, with self-hosted compilers other than GCC, our recipes are
simply downloading pre-compiled binaries for the latest version of the
compiler.  This makes us more vulnerable than necessary, because it
means that every time we update one of these compilers, that is a new
opportunity to get hacked.

Instead, I would prefer to do something closer to what we do in our core
bootstrap.  We should produce our own bootstrap binaries for each of
these self-hosted compilers.  Like our GCC bootstrap binaries, these
binaries should be updated very rarely.  Then, we should use our own
bootstrap binaries to build the latest version of any self-hosted
compiler.  In some cases, if the bootstrap binaries are too old to build
the latest compiler, this might involve multiple steps.

Just as we have recipes to produce bootstrap gcc and binutils, we should
have recipes to build bootstrap binaries for each self-hosted compiler
in our system.  Each time we produce an updated bootstrap compiler from
an earlier one, it should be done with our deterministic package such
that this update step can be independently verified by anyone who wishes
to do so.

What do you think?

      Mark

Re: How to reduce our vulnerability from self-hosted compilers

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Instead, I would prefer to do something closer to what we do in our core
> bootstrap.  We should produce our own bootstrap binaries for each of
> these self-hosted compilers.  Like our GCC bootstrap binaries, these
> binaries should be updated very rarely.  Then, we should use our own
> bootstrap binaries to build the latest version of any self-hosted
> compiler.  In some cases, if the bootstrap binaries are too old to build
> the latest compiler, this might involve multiple steps.
>
> Just as we have recipes to produce bootstrap gcc and binutils, we should
> have recipes to build bootstrap binaries for each self-hosted compiler
> in our system.  Each time we produce an updated bootstrap compiler from
> an earlier one, it should be done with our deterministic package such
> that this update step can be independently verified by anyone who wishes
> to do so.
>
> What do you think?

It think it’s a good idea, but I wonder if it is generally applicable.

For instance, ISTR that GHC can be built with a couple of older versions
whereas MIT Scheme may well require itself.  What exactly is possible is
not always well-documented and sometimes only known to few people.

Maybe we should try to apply it to some of the cases that we have, and
see how well that works?

Thanks,
Ludo’.

Re: How to reduce our vulnerability from self-hosted compilers

[Federico Beffa]

ludo@gnu.org (Ludovic Courtès) writes:

> It think it’s a good idea, but I wonder if it is generally applicable.
>
> For instance, ISTR that GHC can be built with a couple of older versions
> whereas MIT Scheme may well require itself.  What exactly is possible is
> not always well-documented and sometimes only known to few people.

For GHC (at least currently) it is well documented, see
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Tools

In principle I agree with Mark's suggestion. However, I have a couple of
comments.

My intention was to build GHC and get rid of the required GHC bootstrap
binary from GUIX altogether. With the current patch the store doesn't
need to include the bootstrap binaries which, when uncompressed,
requires 940MB! The compressed bootstrap binary archive is "only" 68MB.
(I'm thinking about download time here. But maybe we could force a local
"build" as discussed for TeXLive.)

The other point is: given that we know the hash of the tar file, if
somebody manages to hack them, we will detect it.

Regards,
Fede

Re: How to reduce our vulnerability from self-hosted compilers

[Andreas Enge]

Hello,

your ideas sound good to me. As to Fede, it occurred to me that we would
not need to maintain our own bootstrap binaries as we do for the guix system.
Instead, we could add a fixed binary from upstream to the store (as a
separate, probably private, package) and use it to build the final package.
When updating to a newer version, we would keep the same binary bootstrap
package. This would be an easier way of achieving your first goal.

It would not, however, achieve your second goal, of creating new bootstrap
binaries with the old ones, if necessary, and to thus obtain a complete
"trust chain". But I think this would be the second step, and maybe too much
effort for not so much effect.

Let us implement the first step first, and then see where it leads us.

Andreas