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.
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?
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.
Really? It's a bit of a nonsense that I did so long ago so it's weird to hear someone interested in it...
The script has been lost to time. I wrote it 5+ computers ago and I don't even know where input that backup...
The overall gist is that CGI Bin specification sets Environmental variables, STDIN and STDOUT to various values. A minimal pure assembly that writes <h1> Hello World </h1> over stdout is your minimalist CGI Script.
A bit of research into what those STDIN/Environmental variables is needed for more. I knew this may e 20+ years ago but have long forgotten....
With access to the various input parameters offered over CGI, you can easily access form data (buttons and whatever clicked by the user). Use some smart file writing to store sessions and off you go....
-------
Maybe start with a Perl CGI tutorial. Then go backwards to C, and finally raw assembly by hand
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.
Implementing a web server that can do CGI is actually probably easier than writing a CGI app. All you have to do for your server is set some environment variables and then spawn the executable.
It was a small "app". But I do remember writing string parsers in Assembly.
My overall lesson was to stick with Perl / CGI-bin.
That being said, I wrote in "Human Readable Assembly" back then. Ex: function calls were:
mov eax, string
call myFunction
.db '\n' ; this parameter for myFunction
I would put compile time constants after the functions. Then I would before returning, pop the return address off the stack and add reg, 1, and push it back on.
It's horribly inefficient to do this today. But it allows you to write more flexible assembly functions that were more readable. Especially with macro-assemblers with some kind of preprocessor.
Good luck with your RISC-V asm stuff! Hit me up if you publish any of it :)