Hacker News: imtomt

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 21:47:35 +0000

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 :)

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 21:43:29 +0000

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.

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 21:07:02 +0000

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.

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 21:03:42 +0000

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.

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 20:58:32 +0000

The language matters much less than the architecture of the web server. A server written in assembly using a fork-on-request model like ymawky is going to be much slower than a server written in C using an async event loop like nginx, because forking is very inefficient at scale. Plus a big bottleneck is the networking syscalls, rather than the code itself, so two servers with the same model written in Assembly and C would likely be roughly equal.

New comment by imtomt in "Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason"

imtomt — Tue, 23 Jun 2026 20:48:53 +0000

Thank you! Definitely, some macros would probably be super helpful. Register renaming, too, I'm sure. When I started this project I didn't even know about register renaming lol, and at this point it's so big I'd have to dig pretty deep to find 'em all. Definitely worth doing, though, I'm sure.

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

imtomt — Tue, 23 Jun 2026 04:28:14 +0000

This is ymawky, a now-dynamic web server written entirely in ARM64 Assembly. I've previously posted about ymawky here: https://news.ycombinator.com/item?id=48080587

In the past month and a half, I've made some pretty major improvements: I've added CGI scripting support, so the server now supports query strings and dynamic content; and I've fully ported ymawky to run on Linux, rather than macOS-only.

In addition to GET/PUT/HEAD/DELETE/OPTIONS requests, because of CGI support ymawky also accepts POST requests (only to CGI resources for now).

I've also updated the more detailed writeup to reflect CGI support and the Linux port: https://imtomt.github.io/ymawky/

Comments URL: https://news.ycombinator.com/item?id=48640278

Points: 51

# Comments: 26

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Wed, 13 May 2026 23:03:55 +0000

slowloris mititgations actually weren't too bad, just a couple syscalls to setitimer(), sigaction(), and setsockopt(). Range header parsing was awful, so was content length. I'd say all in all, probably Range headers. Just string parsing in general is pretty awful in assembly.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Mon, 11 May 2026 11:25:58 +0000

Thank you. My favorite reasons for projects are "just because I wanted to" and "because someone told me I shouldn't", and this one ticks both boxes, haha.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 23:10:27 +0000

Oh wow! Your project was actually really inspiring to me, thank you for making this. I was really impressed reading through it a while back. Is it alright if I add a link to your repo in my README?

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 22:21:45 +0000

Aw, that’s too bad. Sounds like it was a really fun project.

Thanks for the tips on CGI! Definitely going to look into it more. The server-side execution of CGI scripts definitely interests me more than the CGI scripts themselves, so I’ll probably just look for some existing (simple) CGI scripts and work on building the env vars and executing them.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 21:02:39 +0000

It would be possible, but impractical for where this project is now. In retrospect, I could have written it with more portability from the start, but since it was just a personal learning project I didn’t think too hard about it. Aside from syscall numbers all being different (which would just require changing the consts in defs.S), syscall numbers are stored in the x16 register on MacOS vs x8 on Linux, and the kernel is called with svc #0x80 on MacOS vs svc #0 on Linux. The bigger issue at this point is MacOS-specific syscalls. proc_info() doesn’t exist on Linux, so that would need to be rewritten. The sigaction struct also has different members (Linux doesn’t have sa_tramp), as well as every other struct having different offsets and sizes. getdirentries64() also doesn’t exist on Linux, it has getdents64() which is called differently and has different output as well I believe, so directory.S would need to be reworked too.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 08:34:40 +0000

Woah! I honestly feel more intimidated writing a CGI script in assembly than I was writing a server, lol. CGI support has been on my mind for a couple weeks, but I haven't really dug into it yet. I'd love to see yours if it's hosted anywhere! Could be a great reference when I do.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 07:31:44 +0000

Yeah, that's what I realized during this, too. You need to be much more explicit, but the way any given function works isn't fundamentally different. "strlen" will always iterate through a string searching for a NULL byte whether it's in C, Rust, Assembly, or whatever other language. I think it can feel almost more straightforward than other languages, since you're laying out exactly what the CPU needs to do, in what exact order.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 07:23:39 +0000

That's so cool! I would love to see it if you're sharing it anywhere.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 06:00:36 +0000

Yeah, I know MacOS syscalls aren't stable. Interesting point about Go, I hadn't heard about that. Unfortunately I'm a masochist though, and want to avoid libSystem.dylib as much as possible. The only reason I link against it at all is because MacOS requires it for executables to run, I never actually call into it. Figured I'd just update the syscall numbers if/when they change.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 05:54:35 +0000

Honestly haven't benchmarked it, but I would imagine ymawky would be considerably slower than most fully-featured web servers. ymawky uses fork-per-connection, which is fundamentally slower than what production servers like nginx or Apache use. nginx uses event-driven IO (kqueue/epoll), which can handle thousands of concurrent connections without the overhead of forking the process on each request. Apache uses pools of threads which handle multiple connections without needing to be spawned per-request. A head-to-head against any other web server would mostly measure "fork-per-connection vs event loop/thread pools", which assembly has nothing to do with.

In a comparison between a similar fork-per-connection server written in C and this, I would imagine the throughput would be about the same, because the bottleneck in this model is fork() itself rather than the actual code. It probably matters more for binary size and startup time than requests/sec. Would be fun to actually benchmark, though.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 05:24:09 +0000

Ahh you caught me. I just kept telling ChatGPT dot com "no, make it less efficient" and copied whatever output it gave me. jk, thank you!

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 05:18:14 +0000

Woah, that's really cool! I'm glad you did that even if you didn't need to. I honestly think everyone needs to write more assembly, because it's so much cooler.

New comment by imtomt in "Show HN: Building a web server in assembly to give my life (a lack of) meaning"

imtomt — Sun, 10 May 2026 05:08:42 +0000

Honestly, just reading existing assembly to get a feel for how it works, and then violently googling everything that goes wrong. The ARM Architecture Reference Manual (aka "The ARM ARM") ended up being really helpful for looking up what specific instructions do and how they're called. Another really helpful tool is writing something in C/C++, and compiling with "gcc -O1 -S file.c" to see the assembly gcc generated. It helps to mess around a lot with smaller programs in gdb or lldb.