[lkml]   [2021]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: pt_regs->ax == -ENOSYS
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.


 \ /
  Last update: 2021-04-28 02:06    [W:0.065 / U:2.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site