Just a friendly reminder that syscall() is a vararg function. Meaning, you can't just go throwing arguments at it (so maybe it's better to use this wrapper to avoid problems instead).
For example, on a 64-bit arch, this code would be sus.
The last argument would be on the stack instead of in a register which is where the kernel expects to find the arguments. But a proper syscall implementation would handle this just fine (e.g. <https://github.com/bminor/glibc/blob/ba60be873554ecd141b55ea...>), so I don't think there's anything sus about it.
The problem is something a bit else (jstarks figured it out somewhere below). I'm not a compiler/abi eng, but it seems to depend on a compiler, eg. consider this with clang-16:
#include <sys/syscall.h>
#include <unistd.h>
#include <alloca.h>
#include <string.h>
void s(long a, long b, long c, long d, long e, long f, long g) {
}
int main(void) {
long a = 0xFFFFFFFFFFFFFFFF;
s(a, a, a, a, a, a, a);
syscall(9999, 1, 2, 3, 4, 5, 6);
return 0;
}
I think you misunderstand. The red zone is on the opposite side of rsp. This line is trying to read an argument that may not exist, relying on the fact that this will put garbage in the register which syscall then ignores. But this only works if the memory is readable.
They are not some professor in my school, some valued colleague, or known kernel expert. They are a stranger on the internet. No, I can't be bothered to research every person that claim to have some wisdom that they won't articulate to cultivate an air of mystery.
Professors get paid, we got a pointer and a lesson for free.
Here's a free dollar. "Only one?"
They said the word "vararg". That is everything. You take that, and you say "oh shit, right, thanks for the heads up" or if you don't already know what's so special about that, you do know they obviously said that for some reason so you fucking google it.
Either way, they pointed you in the right direction, and that is helpful.
The further reading that you find so unbearable takes you exactly the same time to read something that has already been written and is just sitting out there to look up for free, as to read something you demand they write again on the spot bespoke for you.
And since as you say they aren't a proffessor or colleague you personally know and respect, why do you care if they write out a full article or just a pointer? You just said you don't trust a rando. You don't trust their full article anyway.
How do I know if they are "pointing me in the right direction"?
Once again, you assume the conclusion that their comment is helpful and correct and meaningful, and you work backwards to excuse their poor explanation that they justified with "let's say it's a quiz".
And if you don't like my reply, take your own advice and go away. Why do you care what I think of their phrasing? You're not going to get me to stop anyway, or the dozens or people who upvoted me.
Or keep swearing at me and getting downvoted, whatever floats your boat.
"How do I know if they are "pointing me in the right direction"?"
How do you justify complaining about how little they wrote for you when you will ignore them anyway, because "how do I know they are pointing me in the right direction?"
I guess if the arch’s varargs conventions do something other than put each 32-bit value in a 64-bit “slot” (likely for inputs that end up on the stack, at least), then some of the arguments will not line up. Probably some of the last args will get combined into high/low parts of a 64-bit register when moved into registers to pass to the kernel. And then subsequent register inputs will get garbage from the stack.
Need to cast them to long or size_t or whatever to prevent this.
For example, on a 64-bit arch, this code would be sus.
syscall(__NR_syscall_taking_6_args, 1, 2, 3, 4, 5, 6);
Quiz: why
PS: it's a common mistake, so I thought I'd save you a trip down the debugging rabbit hole.