Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
imtomt
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
imtomt
3mo ago
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
2.
▲
by
imtomt
3mo ago
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.
3.
▲
by
imtomt
3mo ago
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. Th
4.
▲
by
imtomt
3mo ago
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
5.
▲
by
imtomt
3mo ago
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, becau
6.
▲
by
imtomt
3mo ago
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
7.
▲
Show HN: A pure ARM64 Assembly web server, now on Linux with CGI for no reason
(github.com)
51 points
by
imtomt
3mo ago
|
26 comments
8.
▲
by
imtomt
4mo ago
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
9.
▲
by
imtomt
4mo ago
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.
10.
▲
by
imtomt
4mo ago
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?
11.
▲
by
imtomt
4mo ago
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 p
12.
▲
by
imtomt
4mo ago
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
13.
▲
by
imtomt
4mo ago
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
14.
▲
by
imtomt
4mo ago
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 byt
15.
▲
by
imtomt
4mo ago
That's so cool! I would love to see it if you're sharing it anywhere.
16.
▲
by
imtomt
4mo ago
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
17.
▲
by
imtomt
4mo ago
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 Ap
18.
▲
by
imtomt
4mo ago
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!
19.
▲
by
imtomt
4mo ago
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.
20.
▲
by
imtomt
4mo ago
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 u
21.
▲
by
imtomt
4mo ago
Thank you! This is one of the nicest things I've heard in a while.
22.
▲
by
imtomt
4mo ago
Why stop there? Next, I'm prying open a CPU and poking the transistors with a 9V battery and paperclips to make it execute what I want. Slower, but you get so much control .
23.
▲
by
imtomt
4mo ago
Thanks for the link, bookmarking. I should note ymawky's main portability issues are unfortunately at the syscall layer rather than the asm layer. proc_info() and getdirentries64() are pretty Darwin-specific, so making it portable woul
24.
▲
by
imtomt
4mo ago
I wrote it for MacOS because I don't have a Linux machine right now :( Once I get one up and running again, I'll probably work on porting this. As for why it wouldn't run on Linux, there are some pretty big differences in the
25.
▲
by
imtomt
4mo ago
Thank you! The thing about eventually building your own meta language ends up happening all the time with bigger assembly projects. I do have a fair few quality-of-life macros too, but probably fewer than I should. I did end up needing to i
26.
▲
by
imtomt
4mo ago
Hey, thank you! Means a lot. It's an odd sort of meditation, but is surprisingly the most almost-therapeutic project I've worked on. Something about the constraints of Assembly that really pull you into the minutiae and clears you
27.
▲
by
imtomt
4mo ago
Honestly, read the main file, ymawky.S first. Then I'd read through get.S maybe, checking parse.S on an as-needed basis for parsing-related functions. delete.S or options.S are pretty short, too, so give those a read too. Modularizing
28.
▲
by
imtomt
4mo ago
Thank you! I've been obsessed with this idea for a while, finally decided to start on it, then obsessed over it for a couple weeks. I'd love to see some of your projects if you have anything similar, I'm glad I'm not the
29.
▲
by
imtomt
4mo ago
That book is exactly what inspired me to make this in the first place, haha. The subtitle of the book gave me the acronym I named it.
30.
▲
by
imtomt
4mo ago
Thanks, I appreciate it a lot! I tried to comment my code pretty heavily (~3000 lines of code, ~1000 lines of comments all together), since this was a learning project for myself in the first place. Hopefully those will be of some use. But
More ›