Mes Becomes An Official GNU Project, Mes 0.17 Released To Bootstrap GNU/Linux Distros

[pal666]

- it requires NO independent external laptop for the first stage. Everything including the first scheme interpreter is self hosted on the new machine.

you can't self host anything without independent external laptop, unless target computer comes with required tools in bios, but then it could come with modern gcc

- by starting simple (easily reviewable) it is virtually immune to the Ken Thompson compiler attack

not really. you can't use magic to review it, you need your external laptop which could already be attacked and showing you wrong pictures

[grigi]

I'l imagine something like this would be good for a new architecture. You first want to validate that your system is capable of booting and working right.
The simpler your software env is, the easier it is to debug/fix.

So you start with a very simple scheme interpreter, and get that to pass its tests, so now you know about many mismatches between designed and reality. Because mistakes are made at all stages, just some you can work around cheaply.

[DrYak]

you can't self host anything without independent external laptop, unless target computer comes with required tools in bios, but then it could come with modern gcc

It could come with it, but won't necessarily.
Hence the point of using Scheme, in their opinion that's about the simplest thing you can manually implement and could do it using just about anything, so probably including whatever is available in the new gcc-less platform you're targetting.

NOTE: It's just a though experiment. In practice, nowadays anything that isn't a desktop/laptop almost automatically comes with Linux support.
But you could for the sake of the though experiment think something as a future smartphone/tablet from google that comes with Fuschia OS, and google's weird userland and no usable compiler.
The point of Mes is that by starting with this smartphone/tablet and only it, you can incrementally get your self the whole GNU userland, starting with the simplest thing that you need to design.

Of course, that's just Mes' idea. You could as well bank on the browser supporting full Javscript and Webassembly, and simply run a virtual machine on it (see all the various JS based emulators) with a full GNU userland from which to cross-compile.

not really. you can't use magic to review it, you need your external laptop which could already be attacked and showing you wrong pictures

That's not the point of Ken Thompson's idea. Look up on the "compiler attack".

It's a though experiment about open source. Even if you have a known good, perfectly safe source code for a C compiler, you'd need to compile it to make use of it.
But it might happen that (unkown to you) the only executable compiler available to you is an "evil" executable that , when provided with a safe source code, will subreptitiously slip in it's "evil" part, and make an "evil" compiler executable out of proven innocent source code. It's a sort of self-replicating binary virus that is carried around by compilers, if you prefer.

It's a though experiment about the limits of the source code. Even if you know the source code, you can't guarantee the binary.
The source code is taken for proven sure in this context. The whole discourse is about how to trust any binary produced out of it.
(The though experiment also takes for granted that nobody sane is going to review every single opcode in the giant binary of the compiler using only a hexeditor).

Every now and then, it's get pointed out by clueless people as a "proof" that open source and linux will never work.

The classical solution to this attack is reproducible built.
Take as many different compilers as you can. Some of them will be regular garden variety compiler, other might happen to be "evil" compilers.
Take your known-good source (e.g.: GCC's source code with an exact SHA256sum)
Compile it with each of the compiler. Of course at this point, each executable will obviously look slightly different because each will be produced by a different compiler (a GCC compiled by Microsoft Visual C++ won't look like one compiled by mingW :-P )
But now you have multiple samples of the exact same version of GCC. These will (supposedly) produce similar result.
So take all your first-step compilers and recompile you known-good source using the usual "reproducible builds" methods.
All these second stage output should be the exact same.
You can now sport the copies that are infected by the "evil" compiler attack because they will diverge from the normal binaries.

( ^- this is how a lot of secure software, including tor, some cryptocoin wallets, etc. are compiler in the real-world).

Here the Mes solution is different :
do not start with a pre-existing compiler, start with something else, something so simple that you can built it yourself manually (a scheme interpreter) and then progressively grow complex until you can run GCC.
You'll never run into the risk of an "evil" compiler contaminating your thing.

[rene]

The logic is different. Let's say that there's a new machine that pop-up (a new hardware constructor making a RISC-V platform). Somebody has to write and then compile the first Linux (or any other OS that uses GNU userland) system on it.

The GCC Canadian Cross approach :
- you take you trusty old laptop with Linux on it, and you compile the basics tools on it by asking your laptop's compiler to target RISC-V architecture.

The MES approach :
- whatever the exotic machine there, scheme is about one of the easiest interpreter to implement any where. As long as it not in kiosk mode, lots of hacker could "just write" a scheme interpreter. The scheme interpreter could be used to make a (very simply) C compiler, not a very good one, but enough to compile a good C/C++ compiler written in ANSI C, and THAT new good compiler would probably support a sizeable chunk of C and C++ modern standards. Thus it can build the GNU basic tools.

The MES approach is problematic because it require multiple stages.

But it has few advantages :
- it requires NO independent external laptop for the first stage. Everything including the first scheme interpreter is self hosted on the new machine.
- by starting simple (easily reviewable) it is virtually immune to the Ken Thompson compiler attack. You have a clear chain of trust between the first scheme interpreter you wrote, and then all the successive step where you feed known good opensource to already trusted previous steps.

The later part is interesting, it's an entirely different approach against compiler attack, compared to the classical "multiple parallel reproducible builds" solution to the attack.

In the end you want GC or LLVM/Clang anyway. So I do not see a single benefit, only a massive amount of more overcomplicated mess that is neither needed, nor normally used. Few people will enjoy reading and writing Scheme neither ;-)

[pal666]

That's not the point of Ken Thompson's idea. Look up on the "compiler attack".

i know it. and trust in your editor is no less important than trust in your compiler

[ArneBab]

- whatever the exotic machine there, scheme is about one of the easiest interpreter to implement any where. As long as it not in kiosk mode, lots of hacker could "just write" a scheme interpreter. The scheme interpreter could be used to make a (very simply) C compiler, not a very good one, but enough to compile a good C/C++ compiler written in ANSI C, and THAT new good compiler would probably support a sizeable chunk of C and C++ modern standards. Thus it can build the GNU basic tools.

And that’s why GCC 4.7 is targeted: GCC 4.7 can build GCC 8.

So for a new platform you only need to run the full bootstrap once, and then you have a trusted GCC, built purely from source without any potentially compromised binaries needed in the process.

This provides a complete source path to any program. And that’s something which had been lost for many years: we were not able to create a program without relying on existing binaries. This is now fixed — or will be fixed once MES is integrated into the bootstrap process of GNU/Linux distributions. Note that one suffices: The others can than take the GCC from that one distro as bootstrap binary and benefit from the full source path, too.

[ArneBab]

i know it. and trust in your editor is no less important than trust in your compiler

That’s for sure. To get this perfect, you need a system built from source to check MES. But it is much easier to check what the editor shows you: just compare a self-written minimal output with what you see in the editor. As long as there is little enough code, you can do this check. That’s why MES is as small as possible.