Re: [Regression v4.2 ?] 32-bit seccomp-BPF returned errno values wrong in VM?

From: Andy Lutomirski
Date: Thu Aug 13 2015 - 18:59:15 EST

On Thu, Aug 13, 2015 at 3:54 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Aug 13, 2015 at 3:49 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Does the attached patch make sense and work?
> Btw, I'm not all that happy with it anyway.
> I still think Denys' patch also potentially changed what audit and
> strace see for %rax in the pt_regs to -ENOSYS, which I'm not convinced
> is a good change.

For better for for worse, the native 64-bit path changed several
versions agi, and nothing broke that I'm aware of. The change was:

commit 54eea9957f5763dd1a2555d7e4cb53b4dd389cc6
Author: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
Date: Fri Sep 5 15:13:55 2014 -0700

x86_64, entry: Treat regs->ax the same in fastpath and slowpath syscalls

AFAIK, ptrace has always seen ax == -ENOSYS on syscall entry for
native 64-bit syscalls. My change just simplified the fast path
(which is invisible by ptrace for obvious reasons, unless someone
traces fork or something along those lines *without*) and made it less
different from the slow path. (IIRC it also simplified some stuff
down the road.)

Looking at 3.19's ia32entry.S, it has:

jz sysenter_auditsys
movq $-ENOSYS,RAX(%rsp)/* ptrace can change this for a bad syscall */

So I think it's always been the intent and practice that ptracers
would see ax == -ENOSYS on syscall entry.

IOW, whether this is good or bad, I don't think it's really a change.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at