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

Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

github.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#21

Post by imtomt »

benj111 wrote: post #3

Cool. I particularly like the O'Reilly book cover that never was. Although I fear you may have misunderstood what wasm is... Question/critique. Isn't getting the mime type by file extension a bit windowsy? Would it not be easier to read the magic number when you're at the assembly level?

You could do that, but it's not really necessary, and adds extra overhead and complexity. And as the other commenter pointed out, it wouldn't work for text file types without magic numbers. I considered reading the magic number at first, but after doing more research, I've found most web servers (nginx and apache, anyway) just match based on file extension. I figure if it's good enough for them, it's good enough for ymawky.

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#22

Post by imtomt »

mrbluecoat wrote: post #12

> written entirely by-hand in ARM64 assembly as a fun project. It's probably got a lot of vulnerabilities I'm unaware of Impressive, but that second part worries me. I hope one day AI security scans upon commit (or integrated in the IDE) will alleviate that risk. What's the current security gold standard for web servers? Hiawatha? https://hiawatha.leisink.net/

Well, if security is a major concern, definitely don't use ymawky in production! That said, I did try my best to harden it. I've fuzzed the parser extensively with afl-fuzz, and got several hours without a single hang or crash. There's no major vulns I'm aware of, but in a ~4500 SLOC assembly project, there's probably gonna be some vulnerabilities that are hiding.

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#23

Post by imtomt »

radhitya wrote: post #9

"raw syscalls only: no libc wrappers" insane! i wonder how many times you have spent to learn about them!

Honestly it's easier than you'd think! All the syscall numbers are in /usr/include/asm-generic/unistd.h (on linux), and you can read the man page for any of them.

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#24

Post by imtomt »

sylware wrote: post #10

arm64 is an IP-locked ISA, namely it is not worth assembly writting, stick to plain and simple C. RISC-V is. I am self-hosting many of my internet thingies. I plan to move to RISC-V only hardware and to rewrite my internet software directly in mono-threaded paranoid RISC-V assembly.

For sure. My laptop has an arm64 chip, which is why this is written in arm64. If I had an intel chip, it would be written in x86_64. RISC-V is very interesting, though, and I'd love to learn more at some point.

Good luck with your RISC-V asm stuff! Hit me up if you publish any of it :)

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#25

Post by sylware »

jprjr_ wrote: post #16
AntronX wrote: post #14

Earlier quoted context omitted.

> arm64 is an IP-locked ISA, namely it is not worth assembly writting Why is that a problem? Google search returns 3K page arm64 ISA manual. What else do you need to write asm?

Nothing else, I think what the're more concerned with is how open an architecture is. I think with RISC-V if you wanted to design your own chips and stuff you can just do it, whereas ARM doesn't let you do that. I'm not about to build my own chips so it doesn't matter all that much to me but I understand where the person is coming from. They'd rather write assembly for the more open architecture.

Exactly what I am doing: I have even a small interpreter to run RISC-V machine code, to a certain extend ofc, on x86_64, and I could just do that on arm64 too: since The 'R' is RISC-V, means "Reduced", such implementation is more than reasonable, even for one average dev.

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#26

Post by sylware »

imtomt wrote: post #24
sylware wrote: post #10

arm64 is an IP-locked ISA, namely it is not worth assembly writting, stick to plain and simple C. RISC-V is. I am self-hosting many of my internet thingies. I plan to move to RISC-V only hardware and to rewrite my internet software directly in mono-threaded paranoid RISC-V assembly.

For sure. My laptop has an arm64 chip, which is why this is written in arm64. If I had an intel chip, it would be written in x86_64. RISC-V is very interesting, though, and I'd love to learn more at some point. Good luck with your RISC-V asm stuff! Hit me up if you publish any of it :)

I have a good set of RISC-V thingies on internet already, but not cleanely in some git repositories (obsviously not on microsoft github.com or gitlab).

I am currently attempting to define some binary specifications for a wayland compositor on linux, and to do that I write RISC-V assembly which I run on x86_64 thx to a very small interpreter. So the "cleanup" will happen "after" I get my own real-life wayland compositor (I am currently finishing the memory layout for keyboard and mouse support if you were curious about it).

Letting people know here is seriously compromised: HN started to aggressively block web browsers which are not based on one of the 'whatwg cartel' web engines, or their security provider is in love with gogol, dunno, could be my internet lines actively filtered too :) noscript/basic HTML is the only way for web freedom.

Re: Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason

#27

Post by ntm3c »

Lucasoato wrote: post #11

Is an assembly webserver more performant than webservers written in other languages? Are there any hard limits on how much you can squeeze when using a particular framework?

Assembly can provide the best raw performance because it's closer to the hardware. However, writing and maintaining a web server in Assembly takes much more time, and in many cases the performance gain over a well-written C program is small.
Post reply on HN