Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 2 Aug 2012 09:54:43 -0700 | Subject | Re: [PATCH 3.5 2/2] seccomp: Future-proof against silly tracers |
| |
On Thu, Aug 2, 2012 at 7:32 AM, Will Drewry <wad@chromium.org> wrote: > On Thu, Jul 26, 2012 at 10:41 AM, Andy Lutomirski <luto@amacapital.net> wrote: >> On Tue, Jul 17, 2012 at 4:19 PM, Andy Lutomirski <luto@amacapital.net> wrote: >>> Currently, if a tracer changes a syscall nr to __NR_future_enosys, >>> behavior will differ between kernels that know about >>> __NR_future_enosys (and return -ENOSYS) and older kernels (which >>> return the value from pt_regs). This is silly; we should just >>> return -ENOSYS. >>> >>> This is unlikely to ever happen on x86 because the return value in >>> pt_regs starts out as -ENOSYS, but a silly tracer can change that. >>> >>> Signed-off-by: Andy Lutomirski <luto@amacapital.net> >>> Cc: Will Drewry <wad@chromium.org> >>> --- >>> arch/x86/include/asm/syscall.h | 11 +++++++++++ >>> kernel/seccomp.c | 15 +++++++++++++++ >>> 2 files changed, 26 insertions(+), 0 deletions(-) >> >> Will, can you pick this, or some version of it, up in your >> seccomp-for-ARM tree or wherever your development is? > > I'm still not sure about this change though the end result is nice. > Regardless, I'll explore it when I can -- my family has just increased > in size, so I'm going to be a bit delayed!
I don't think there's any particular rush here. It's a very minor ABI change, but I had to write code to explicitly look for it to detect any difference at all.
--Andy
> > cheers! > will
-- Andy Lutomirski AMA Capital Management, LLC
| |