Re: pt_regs->ax == -ENOSYS

[H. Peter Anvin]

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