From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: Re: Removing compilers that cannot be bootstrapped Date: Sat, 26 Mar 2016 20:02:56 +1100 Message-ID: <20160326090256.GB17842@jookia-eeepc.Home> References: <87twjz4fcn.fsf@gnu.org> <87h9fyw3j8.fsf@dustycloud.org> <87bn64u9mc.fsf@gnu.org> <87lh58izcy.fsf@dustycloud.org> <20160324031126.GA22569@jasmine> <87d1qi40me.fsf@gnu.org> <20160326002235.GA3676@jasmine> <87io09bv2s.fsf@gmail.com> <87egaxbudr.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ajk7w-0005lR-W3 for guix-devel@gnu.org; Sat, 26 Mar 2016 05:03:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ajk7s-0004N9-0m for guix-devel@gnu.org; Sat, 26 Mar 2016 05:03:24 -0400 Received: from mail-pa0-x242.google.com ([2607:f8b0:400e:c03::242]:36709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ajk7r-0004Ml-Lr for guix-devel@gnu.org; Sat, 26 Mar 2016 05:03:19 -0400 Received: by mail-pa0-x242.google.com with SMTP id 1so9008322pal.3 for ; Sat, 26 Mar 2016 02:03:19 -0700 (PDT) Content-Disposition: inline In-Reply-To: <87egaxbudr.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Chris Marusich Cc: guix-devel Hey, I have a few quick notes that aren't that relevant. On Fri, Mar 25, 2016 at 11:55:44PM -0700, Chris Marusich wrote: > > 1) Write the simplest possible program (or collection of programs) in > > the simplest possible machine code. This program serves only one > > purpose: to enable you to write more code at a higher level of > > abstraction. It is effectively a compiler for a very primitive > > language, but the language it compiles will be one layer of abstraction > > above machine code, which is a step in the right direction. This first > > program must be a "binary blob", since we cannot rely on any existing > > tools to build it. It must be simple enough that someone can read and > > understand it using e.g. a hex editor, provided that they have access to > > the right reference materials. Since this program exists only as > > machine code, it must be documented thoroughly to make it easier to > > understand. > > > > 2) Write source code which, when compiled using the compiler/toolchain > > From the previous step, produces a new compiler/toolchain that will > > allow you to write more expressive source code at a higher layer of > > abstraction. > > > > 3) Repeat step (2) as many times as necessary to produce a compiler that > > is capable of compiling GCC from source. > > > > 4) Use the compiler from (3) to compile GCC from source. > > > > 5) Use the GCC from (4) to compile the rest of the world from source. > > > > If we want to free ourselves from reliance on inscrutable binary blobs, > > isn't something like that the only way? I think so. We also have to write bootstrap compilers for other languages, which is the other end of the stick being burned here. We also need to figure out how to get the correct source to people with signing. > Sorry for replying to my own post, but I couldn't help myself. If > anyone thinks the above sounds too paranoid, remember the Ken Thompson > hack: > > http://www.c2.com/cgi/wiki?TheKenThompsonHack > > Chilling! I try not to think about security too much when it comes to efforts, after all, it's just a cat and mouse game of probability. I think there was a talk on this by perhaps Ludovic or Dave about how freedom relates to reproducibility. If we can't reproduce something, how can we truly have the source code to modify it? Philosophy aside, I think it's important to know that the clear security benefit here isn't that we can prevent these attacks, but we will have a smaller set of code to audit when we have the tools to take a threat model and prevent threats. For now the closest we could have is to trust whatever platform we're using to boot code that the CPU with faithfully execute. For now it could be BIOS. > -- > Chris Jookia.