imtomt

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

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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