Re: ptrace interface does not permit modification of syscall return

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

On 22 Dec 2015 22:10, Helge Deller wrote:
> On 21.12.2015 18:55, Mike Frysinger wrote:
> > i have a ptrace program that watches for specific syscalls and when
> > matched, will:
> >  - on entry change the syscall nr to -1 (so the kernel will skip it)
> >  - on exit change the return to -EPERM so the userspace sees a denial
> > 
> > i have this working on most arches (x86, x86_64, arm, alpha, ia64, etc...).
> > on parisc, the kernel (using 3.18.7 currently) appears to be wrong.  in my
> > tests, if i don't mess with the syscall nr, i can change the return value
> > fine (to EPERM or whatever).  but the syscall executed which i do not want.
> > if i change the syscall to -1, then i can't change the return value (so the
> > child sees ENOSYS), but the kernel still executes the original syscall.
> > 
> > i have a simple test case attached to show the issue.  the code does:
> >  - spawn a child with the parent tracing it
> >  - child will do:
> >   - dupe stderr to another fd
> >   - unlink a file named ".test.flag"
> >   - write a message through the new fd
> >   - close a magic # so the parent knows to start denying
> >     - should see EPERM but it sees ENOSYS
> >   - close the new fd
> >     - should see EPERM but it is closed!
> >   - write to the new fd
> >     - should work, but the fd is closed
> >   - call create on ".test.flag"
> >     - should see EPERM, but the file is created!
> >  - parent will do:
> >   - log the syscalls until child runs close(-12345)
> >   - the parent will then try to deny all close/creat calls
> >   - uses PTRACE_POKEUSER w/PT_GR20 to set syscall to -1
> >   - uses PTRACE_POKEUSER w/PT_GR28 to set return to -EPERM
> > 
> > you can run the test case by doing:
> > $ gcc test.c && ./a.out
> 
> I agree, something is fishy :-)
> 
> I did some tests with your testcase.
> First problem I had was, that compiling failed since it didn't found the asm/offset.h header file.
> Which one did you used? I know it usually should come with the kernel headers, but there it is asm-offsets.h.

hmm, looks like it got installed by hand at some point (Jul 2004 datestamp!)
and never cleaned up.

> First problem: I had to install the 64bit header file. PT_GR20 in this one was much higher than it should be for 32bit userspace.
> 
> So, I used those defines (taken from the strace source package):
> #define PT_GR20 (20*4)
> #define PT_GR26 (26*4)
> #define PT_GR28 (28*4)
> #define PT_IAOQ0 (106*4)
> #define PT_IAOQ1 (107*4)

these are the values in my local asm/offset.h, and what i was using
in my original code -- the register # multiplied by 4.

> With that I got those output:

looks like you're seeing the same as me.  i'm only testing 32bit user
and 32bit kernel currently as we don't have a 64bit userspace :).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]