| Message ID | 1440563342-5411-1-git-send-email-vapier@gentoo.org |
|---|---|
| State | New |
| Headers | show |
On Wed, 26 Aug 2015, Mike Frysinger wrote: > Linux 3.13 added SIGSYS details to siginfo_t; update glibc's copy to > keep in sync with it. > > 2015-08-25 Mike Frysinger <vapier@gentoo.org> > > [BZ #18863] > * sysdeps/unix/sysv/linux/mips/bits/siginfo.h (siginfo_t): Add _sigsys. > (si_call_addr): Define. > (si_syscall): Define. > (si_arch): Define. OK. CC to linux-mips because I see that the MIPS implementation of copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel.
On 26 Aug 2015 09:30, Joseph Myers wrote: > On Wed, 26 Aug 2015, Mike Frysinger wrote: > > Linux 3.13 added SIGSYS details to siginfo_t; update glibc's copy to > > keep in sync with it. > > > > 2015-08-25 Mike Frysinger <vapier@gentoo.org> > > > > [BZ #18863] > > * sysdeps/unix/sysv/linux/mips/bits/siginfo.h (siginfo_t): Add _sigsys. > > (si_call_addr): Define. > > (si_syscall): Define. > > (si_arch): Define. > > OK. CC to linux-mips because I see that the MIPS implementation of > copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so > I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel. i'm getting reports of seccomp misbehavior on mips already which is what started me down this glibc path. i suspect the original port was tested against o32 kernels only. -mike
On 08/26/2015 06:10 PM, Mike Frysinger wrote: > On 26 Aug 2015 09:30, Joseph Myers wrote: >> On Wed, 26 Aug 2015, Mike Frysinger wrote: >>> Linux 3.13 added SIGSYS details to siginfo_t; update glibc's copy to >>> keep in sync with it. >>> >>> 2015-08-25 Mike Frysinger <vapier@gentoo.org> >>> >>> [BZ #18863] >>> * sysdeps/unix/sysv/linux/mips/bits/siginfo.h (siginfo_t): Add _sigsys. >>> (si_call_addr): Define. >>> (si_syscall): Define. >>> (si_arch): Define. >> >> OK. CC to linux-mips because I see that the MIPS implementation of >> copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so >> I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel. > > i'm getting reports of seccomp misbehavior on mips already which is what > started me down this glibc path. i suspect the original port was tested > against o32 kernels only. > -mike > I have recently tested mips64 n64/n32 with the testsuite from libseccomp and that led me to this fix https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f161439e4104b641a7bfb9b89581d801159fec8 if you are aware of other problems (and perhaps a test to trigger them) that could be kernel related let me know
On Thu, 27 Aug 2015, Markos Chandras wrote: > >> OK. CC to linux-mips because I see that the MIPS implementation of > >> copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so > >> I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel. > > > > i'm getting reports of seccomp misbehavior on mips already which is what > > started me down this glibc path. i suspect the original port was tested > > against o32 kernels only. > > -mike > > > > I have recently tested mips64 n64/n32 with the testsuite from libseccomp > and that led me to this fix > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f161439e4104b641a7bfb9b89581d801159fec8 > > if you are aware of other problems (and perhaps a test to trigger them) > that could be kernel related let me know My observation about copy_siginfo_to_user32 missing a case was purely based on the kernel source code. I've no reason to think it has anything to do with seccomp problems.
On 08/27/2015 10:41 AM, Joseph Myers wrote: > On Thu, 27 Aug 2015, Markos Chandras wrote: > >>>> OK. CC to linux-mips because I see that the MIPS implementation of >>>> copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so >>>> I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel. >>> >>> i'm getting reports of seccomp misbehavior on mips already which is what >>> started me down this glibc path. i suspect the original port was tested >>> against o32 kernels only. >>> -mike >>> >> >> I have recently tested mips64 n64/n32 with the testsuite from libseccomp >> and that led me to this fix >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f161439e4104b641a7bfb9b89581d801159fec8 >> >> if you are aware of other problems (and perhaps a test to trigger them) >> that could be kernel related let me know > > My observation about copy_siginfo_to_user32 missing a case was purely > based on the kernel source code. I've no reason to think it has anything > to do with seccomp problems. > Yeah, my email was directed to Mike who said he is getting reports that seccomp on MIPS has issues and that led him to his glibc patch.
On 27 Aug 2015 09:00, Markos Chandras wrote: > On 08/26/2015 06:10 PM, Mike Frysinger wrote: > > On 26 Aug 2015 09:30, Joseph Myers wrote: > >> On Wed, 26 Aug 2015, Mike Frysinger wrote: > >>> Linux 3.13 added SIGSYS details to siginfo_t; update glibc's copy to > >>> keep in sync with it. > >>> > >>> 2015-08-25 Mike Frysinger <vapier@gentoo.org> > >>> > >>> [BZ #18863] > >>> * sysdeps/unix/sysv/linux/mips/bits/siginfo.h (siginfo_t): Add _sigsys. > >>> (si_call_addr): Define. > >>> (si_syscall): Define. > >>> (si_arch): Define. > >> > >> OK. CC to linux-mips because I see that the MIPS implementation of > >> copy_siginfo_to_user32 doesn't handle __SI_SYS, unlike arm64 at least, so > >> I suspect this won't in fact work for n32 or for o32 with a 64-bit kernel. > > > > i'm getting reports of seccomp misbehavior on mips already which is what > > started me down this glibc path. i suspect the original port was tested > > against o32 kernels only. > > -mike > > > > I have recently tested mips64 n64/n32 with the testsuite from libseccomp > and that led me to this fix > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9f161439e4104b641a7bfb9b89581d801159fec8 > > if you are aware of other problems (and perhaps a test to trigger them) > that could be kernel related let me know i was waiting on kumba to file a bug, and recover my mips box when i got local access to it again to check another report. but if libseccomp is passing its unittests now as n64/n32 userland, i think that should cover things. -mike
diff --git a/sysdeps/unix/sysv/linux/mips/bits/siginfo.h b/sysdeps/unix/sysv/linux/mips/bits/siginfo.h index 3391319..96d406e 100644 --- a/sysdeps/unix/sysv/linux/mips/bits/siginfo.h +++ b/sysdeps/unix/sysv/linux/mips/bits/siginfo.h @@ -107,6 +107,14 @@ typedef struct long int si_band; /* Band event for SIGPOLL. */ int si_fd; } _sigpoll; + + /* SIGSYS. */ + struct + { + void *_call_addr; /* Calling user insn. */ + int _syscall; /* Triggering system call number. */ + unsigned int _arch; /* AUDIT_ARCH_* of syscall. */ + } _sigsys; } _sifields; } siginfo_t; @@ -126,6 +134,9 @@ typedef struct # define si_addr_lsb _sifields._sigfault.si_addr_lsb # define si_band _sifields._sigpoll.si_band # define si_fd _sifields._sigpoll.si_fd +# define si_call_addr _sifields._sigsys._call_addr +# define si_syscall _sifields._sigsys._syscall +# define si_arch _sifields._sigsys._arch /* Values for `si_code'. Positive values are reserved for kernel-generated