Messages in this thread | | | Subject | Re: pt_regs->ax == -ENOSYS | From | "H. Peter Anvin" <> | Date | Tue, 27 Apr 2021 17:05:16 -0700 |
| |
On 4/27/21 4:23 PM, Andy Lutomirski wrote: > > I much prefer the model of saying that the bits that make sense for > the syscall type (all 64 for 64-bit SYSCALL and the low 32 for > everything else) are all valid. This way there are no weird reserved > bits, no weird ptrace() interactions, etc. I'm a tiny bit concerned > that this would result in a backwards compatibility issue, but not > very. This would involve changing syscall_get_nr(), but that doesn't > seem so bad. The biggest problem is that seccomp hardcoded syscall > nrs to 32 bit. > > An alternative would be to declare that we always truncate to 32 bits, > except that 64-bit SYSCALL with high bits set is an error and results > in ENOSYS. The ptrace interaction there is potentially nasty. > > Basically, all choices here kind of suck, and I haven't done a real > analysis of all the issues... >
OK, I really don't understand this. The *current* way of doing it causes a bunch of ugly corner conditions, including in ptrace, which this would get rid of. It isn't any different than passing any other argument which is an int -- in fact we have this whole machinery to deal with that subcase.
If it makes you feel better, we could even sign-extend the value in orig_ax, but that seems unnecessary and a bit broken to me.
-hpa
| |