From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Dr. Roger R. Schell" Newsgroups: gmane.lisp.guile.devel,gmane.comp.gnu.lightning.general Subject: RE: GNU Thunder [Comments on Subversins from Ian Grant and Richard Stallman of GNU] Date: Sat, 6 Sep 2014 08:09:10 -0700 Message-ID: <006501cfc9e4$83215540$8963ffc0$@org> References: Reply-To: schellr@acm.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01CFC9A9.D6C2A450" X-Trace: ger.gmane.org 1410039714 16280 80.91.229.3 (6 Sep 2014 21:41:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2014 21:41:54 +0000 (UTC) To: "'Ian Grant'" , "'Richard Stallman'" , , "'lightning'" , "'Markus Kuhn'" , "'Theo deRaadt'" , "'Linus Torvalds'" , Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Sep 06 23:41:47 2014 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQNju-0000x4-J1 for guile-devel@m.gmane.org; Sat, 06 Sep 2014 23:41:46 +0200 Original-Received: from localhost ([::1]:36310 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQNju-0000vU-7E for guile-devel@m.gmane.org; Sat, 06 Sep 2014 17:41:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQHbq-000462-Mg for guile-devel@gnu.org; Sat, 06 Sep 2014 11:09:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQHbl-0006bL-Lz for guile-devel@gnu.org; Sat, 06 Sep 2014 11:09:02 -0400 Original-Received: from segonax.lunarpages.com ([216.97.227.60]:41463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQHbl-0006b9-8T; Sat, 06 Sep 2014 11:08:57 -0400 Original-Received: from cpe-75-84-53-78.socal.res.rr.com ([75.84.53.78]:50015 helo=RogerX230) by segonax.lunarpages.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XQHbd-0003xW-4z; Sat, 06 Sep 2014 08:08:49 -0700 In-Reply-To: X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/Jc4GcC4hcd0g3Sx6NZgk7B9NTXgAbxyzw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - segonax.lunarpages.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acm.org X-Get-Message-Sender-Via: segonax.lunarpages.com: authenticated_id: roger.schell@aesec.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 216.97.227.60 X-Mailman-Approved-At: Sat, 06 Sep 2014 17:41:36 -0400 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17423 gmane.comp.gnu.lightning.general:575 Archived-At: This is a multi-part message in MIME format. ------=_NextPart_000_0066_01CFC9A9.D6C2A450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Although I agree with several of the comment by both Richard and Ian, = most of what I would have to say is in my comments on subversion found = at http://cisr.nps.edu/downloads/papers/04paper_subversion.pdf Although = written a decade ago, it is still current today. =20 Roger Schell =20 From: Ian Grant [mailto:ian.a.n.grant@googlemail.com]=20 Sent: Friday, September 05, 2014 6:40 PM To: Richard Stallman; guile-devel@gnu.org; lightning; Markus Kuhn; Theo = deRaadt; Linus Torvalds; schellr@ieee.org Subject: Re: GNU Thunder =20 On Thu, Sep 4, 2014 at 9:50 PM, Richard Stallman wrote: There are limits to how much effort we should make to deal with the imponderable possibilities of sabotage. Especially since there is so much else we know that we need to do. To throw away all our software because of these possibilities would not make sense. =20 At no point did I say you _have_ to throw away your software. On the = contrary, I have explained to you precisely how you could have a means = by which you can gain assurance, whenever you need it and at very little = effort, that in fact the software has very probably not been sabotaged. = So instead of putting up what are quite frankly feeble arguments as to = the unlikelihood of such an attack, you could have assurance that it was = _in fact_ improbable, and you would be able to put a figure on the = improbability, and you would be able to explain to anyone who cared to = listen, how you had arrived at that figure. But you think this is a research project.=20 Well I am telling you now, for free, that it is not a research project, = it is something that we can actually implement. Just because _you_ don't = see how it could be done, does not mean it's impossible, because it may = just be the case that there is something about semantics that _you_ = don't know. Now it is clear to everyone that you do not yet understand the problem = because you write=20 > I think our community's distributed build practices would > make it difficult for such a sabotage to hit the whole > community. Many GCC developers and redistributors > have been bootstrapping for decades using their old versions. The GCC developers don't ship object code, do they? So the compiler the = GCC developers use is irrelevant. This is an object code trap door, it = does not need to be in the source code. But I sincerely doubt that the GCC developers have in fact bootstrapped = from their old binaries for decades. What reason would they have to do = that? They are just like me: I use whatever compiler binary is on the = distribution, as long as it is capable of compiling my source, and their = source can be compiled by any old gcc binary. But as I say, this is = irrelevant. The problem is this: it is impossible to bootstrap the GNU tool-chain = from scratch because it's all written in C, and C is too complex a = language to use for a definitional interpreter. So we always rely on the = semantics determined by some C compiler binary, which semantics is what = you call an imponderable. What we need is a language with a simple semantics for which we can = write interpreters from scratch. It will be slow, but that doesn't = matter. All we need it for is to generate the reference compiler that we = know is secure, and the reference tools that we use to verify that the = object code produced by the full 740 MB of GCC source when compiled by = the 74MB gcc binaries, is the same object code our reference compiler = produces. =20 Now I think we can do this with GNU Guile and GNU Lightning. What we = need is the semantics of lightning to be defined as program data: so we = define the expansions of the lightning primitives as assembler in the = various target architectures, and we formally define the mapping the = instruction encoders for the various architectures use to map assembler = to binary machine code instructions. Then we can automatically generate = lightning assemblers in any source language for which we need it. So we can have interpreters for languages that are capable of compiling = their own bytecode interpreters and primitives. For example, Guile will = be able to JIT compile all of what it now ships as C code, from scheme. = So all it will need to bootstrap is a simple scheme interpreter. It = could in in fact write that scheme interpreter itself, just by shipping = out lightning codes implementing its bytecode interpreter, to a = lightning compiler. Of course this scheme interpreter would be = susceptible to sabotage if the lightning compiler were written in C. The thing is A LIGHTNING COMPILER COULD BE TRIVIAL TO WRITE FROM SCRATCH = IF WE ONLY HAD A MACHINE READABLE DEFINITION OF LIGHTNING SEMANTICS. =20 I explained all of this in the PDF I sent to you two weeks ago, and = which I sent to these lists.=20 All we need to do to implement this is to extract the data defining the = instruction encoding that the assembler carries out for the various = architectures, and get Paulo to write a data file formally defining the = process by which lightning translates the lightning opcodes into = assembler in the various architectures it supports. I explained in a = post to that list that this need not be too hard to do: we only need a = core subset of primitives with universal architecture support. Now do you think this is pie in the sky, and "an interesting subject for = research." If so, then why don't you explain to us all _why_ it is that = you think that? Ian ------=_NextPart_000_0066_01CFC9A9.D6C2A450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Although I agree with several of the comment by = both Richard and Ian, most of what I would have to say is in my comments = on subversion found at http= ://cisr.nps.edu/downloads/papers/04paper_subversion.pdf Although = written a decade ago, it is still current today.

 

Roger = Schell

 

From:= = Ian Grant [mailto:ian.a.n.grant@googlemail.com]
Sent: Friday, = September 05, 2014 6:40 PM
To: Richard Stallman; = guile-devel@gnu.org; lightning; Markus Kuhn; Theo deRaadt; Linus = Torvalds; schellr@ieee.org
Subject: Re: GNU = Thunder

 

On Thu, = Sep 4, 2014 at 9:50 PM, Richard Stallman <rms@gnu.org> = wrote:

There are = limits to how much effort we should make to deal with = the
imponderable possibilities of sabotage.  Especially since = there is so
much else we know that we need to do.  To throw away = all our software
because of these possibilities would not make = sense.

 

At no point did I say you _have_ to throw = away your software. On the contrary, I have explained to you precisely = how you could have a means by which you can gain assurance, whenever you = need it and at very little effort, that in fact the software has very = probably not been sabotaged. So instead of putting up what are quite = frankly feeble arguments as to the unlikelihood of such an attack, you = could have assurance that it was _in fact_ improbable, and you would be = able to put a figure on the improbability, and you would be able to = explain to anyone who cared to listen, how you had arrived at that = figure.

But you think this is a research project.

Well I = am telling you now, for free, that it is not a research project, it is = something that we can actually implement. Just because _you_ don't see = how it could be done, does not mean it's impossible, because it may just = be the case that there is something about semantics that _you_ don't = know.

Now it is clear to everyone that you do = not yet understand the problem because you write

> I think = our community's distributed build practices would
> make it = difficult for such a sabotage to hit the whole
> community.  = Many GCC developers and redistributors
> have been bootstrapping = for decades using their old versions.

The GCC developers = don't ship object code, do they? So the compiler the GCC developers use = is irrelevant. This is an object code trap door, it does not need to be = in the source code.

But I sincerely doubt that the GCC = developers have in fact bootstrapped from their old binaries for = decades. What reason would they have to do that? They are just like me: = I use whatever compiler binary is on the distribution, as long as it is = capable of compiling my source, and their source can be compiled by any = old gcc binary. But as I say, this is = irrelevant.

The problem is = this: it is impossible to bootstrap the GNU tool-chain from scratch = because it's all written in C, and C is too complex a language to use = for a definitional interpreter. So we always rely on the semantics = determined by some C compiler binary, which semantics is what you call = an imponderable.

What we need is a language with a simple = semantics for which we can write interpreters from scratch. It will be = slow, but that doesn't matter. All we need it for is to generate the = reference compiler that we know is secure, and the reference tools that = we use to verify that the object code produced by the full 740 MB of GCC = source when compiled by the 74MB gcc binaries, is the same object code = our reference compiler produces.

 

Now I think we can do this with GNU Guile = and GNU Lightning. What we need is the semantics of lightning to be = defined as program data: so we define the expansions of the lightning = primitives as assembler in the various target architectures, and we = formally define the mapping the instruction encoders for the various = architectures use to map assembler to binary machine code instructions. = Then we can automatically generate lightning assemblers in any source = language for which we need it.

So we can have interpreters for = languages that are capable of compiling their own bytecode interpreters = and primitives. For example, Guile will be able to JIT compile all of = what it now ships as C code, from scheme. So all it will need to = bootstrap is a simple scheme interpreter. It could in in fact write that = scheme interpreter itself, just by shipping out lightning codes = implementing its bytecode interpreter, to a lightning compiler. Of = course this scheme interpreter would be susceptible to sabotage if the = lightning compiler were written in C.

The thing is A LIGHTNING COMPILER COULD BE TRIVIAL TO = WRITE FROM SCRATCH IF WE ONLY HAD A MACHINE READABLE DEFINITION OF = LIGHTNING SEMANTICS.

 

I explained all of this in the PDF I sent = to you two weeks ago, and which I sent to these lists. =

All we need to do to = implement this is to extract the data defining the instruction encoding = that the assembler carries out for the various architectures, and get = Paulo to write a data file formally defining the process by which = lightning translates the lightning opcodes into assembler in the various = architectures it supports. I explained in a post to that list that this = need not be too hard to do: we only need a core subset of primitives = with universal architecture support.


Now do you think = this is pie in the sky, and "an interesting subject for = research." If so, then why don't you explain to us all _why_ it is = that you think that?

Ian

=
------=_NextPart_000_0066_01CFC9A9.D6C2A450--