Re: "For What It's Worth" (or How do I know my Gentoo source code hasn't been messed with?)

Lie Ryan posted on Fri, 08 Aug 2014 02:06:14 +1000 as excerpted:

> With you having to compile thousands of stuffs if you build from stage
> 1, I doubt that you will be able to verify every single thing you
> compile and detect if something is actually doing sneaky stuff AND still
> have the time to enjoy your system. Also, even if you build from stage 1
> and manage to verify all the source code, you still need to download a
> precompiled compiler which could possibly inject the malicious code into
> the programs it compiles, and which can also inject itself if you try to
> compile another compiler from source. If there is a single software that
> is worth a gold mine to inject with malware to gain illicit access to
> all Linux system, then it would be gcc. Once you infect a compiler,
> you're invincible.

Actually, that brings up a good question.  The art of compiling is 
certainly somewhat magic to me tho I guess I somewhat understand the 
concept in a vague, handwavy way, but...

From my understanding, that's one reason why the gcc build is multi-stage 
and uses simpler (and thus easier to audit) tools such as lex and bison 
in its bootstrapping process.  I'm not actually sure whether gcc actually 
requires a previous gcc (or other full compiler) to build or not, but I 
do know it goes to quite some lengths to bootstrap in multiple stages, 
building things up from the simple to the complex as it goes and testing 
each stage in the process so that if something goes wrong, there's some 
idea /where/ it went wrong.

Clearly one major reason for that is proving functionality at each step 
such that if the process goes wrong, there's some place to start as to 
why and how, but it certainly doesn't hurt in helping to prove or at 
least somewhat establish the basic security situation either, tho as 
we've already established, it's basically impossible to prove both the 
hardware and the software back thru all the multiple generations.

Of course the simpler tools, lex, bison, etc, must have been built from 
something, but because they /are/ simpler, they're also easier to audit 
and prove basic functionality, including disassembly and analysis of 
individual machine instructions for a fuller audit.

So anyway, to the gcc experts that know, and to non-gcc CS folks who have 
actually built their own simple compilers and can at least address the 
concept, is a previous gcc or other full compiler actually required to 
build a new gcc, or does it sufficiently bootstrap itself from the more 
basic tools such that unlike most code, it doesn't actually need a full 
compiler to build and reasonably optimize at all?  That's a question I've 
had brewing in the back of my mind for some time, and this seemed the 
perfect opportunity to ask it. =:^)

Meanwhile, I suppose it must be possible at least at some level, else how 
would new hardware archs come to be supported.  Gotta start /somewhere/ 
on the toolchain, and "simpler" stuff like lex and bison can I believe 
run on a previous arch, generating the basic executable building blocks 
that ultimately become the first executable code actually run by the new 
target arch.

And of course gcc has long been one of the most widely arch-supporting 
compilers, precisely because it /is/ open source and /is/ designed to be 
bootstrapped in stages like that.  I guess clang/llvm is giving gcc some 
competition in that area now, in part because it's more modern and 
modular and in part because unlike gcc it /can/ legally be taken private 
and supplied to others without offering sources and some companies are 
evil that way, but gcc's the one with the long history in that area, and 
given that history I'd guess it'll be some time before clang/llvm catches 
up, even if it's getting most of the new platforms right now, which I've 
no idea whether it's the case or not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman