Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread H. Peter Anvin
On 05/28/2014 02:53 PM, Philipp Kern wrote: > On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski wrote: >> However: are you sure that entry_64.S handles this? It looks like >> tracesys has higher priority than badsys. And strace can certainly >> see out-of-range syscalls. […] > > Not only can it

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Andy Lutomirski
On Wed, May 28, 2014 at 2:53 PM, Philipp Kern wrote: > On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski wrote: >> However: are you sure that entry_64.S handles this? It looks like >> tracesys has higher priority than badsys. And strace can certainly >> see out-of-range syscalls. […] > > Not on

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Philipp Kern
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski wrote: > However: are you sure that entry_64.S handles this? It looks like > tracesys has higher priority than badsys. And strace can certainly > see out-of-range syscalls. […] Not only can it see them: It must see that this bit is set as that's

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Andy Lutomirski
On Wed, May 28, 2014 at 2:19 PM, H. Peter Anvin wrote: > On 05/28/2014 02:15 PM, Andy Lutomirski wrote: >>> 3. The OOPS you're fixing doesn't seem like it's fixed. What if some other random high bits are set? >>> >>> There is a range check in entry_*.S for the system call. >> >> I can i

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread H. Peter Anvin
On 05/28/2014 02:15 PM, Andy Lutomirski wrote: >> >>> 3. The OOPS you're fixing doesn't seem like it's fixed. What if some >>> other random high bits are set? >> >> There is a range check in entry_*.S for the system call. > > I can imagine that causing a certain amount of confusion to fancy > sec

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Andy Lutomirski
On Wed, May 28, 2014 at 2:01 PM, H. Peter Anvin wrote: > On 05/28/2014 01:47 PM, Andy Lutomirski wrote: >> On 05/28/2014 05:19 AM, Philipp Kern wrote: >>> audit_filter_syscall uses the syscall number to reference into a >>> bitmask (e->rule.mask[word]). Not removing the x32 bit before passing >>>

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread H. Peter Anvin
On 05/28/2014 01:47 PM, Andy Lutomirski wrote: > On 05/28/2014 05:19 AM, Philipp Kern wrote: >> audit_filter_syscall uses the syscall number to reference into a >> bitmask (e->rule.mask[word]). Not removing the x32 bit before passing >> the number to this architecture independent codepath will fail

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Philipp Kern
On Wed, May 28, 2014 at 10:47 PM, Andy Lutomirski wrote: > On 05/28/2014 05:19 AM, Philipp Kern wrote: > > audit_filter_syscall uses the syscall number to reference into a > > bitmask (e->rule.mask[word]). Not removing the x32 bit before passing > > the number to this architecture independent code

Re: [PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Andy Lutomirski
On 05/28/2014 05:19 AM, Philipp Kern wrote: > audit_filter_syscall uses the syscall number to reference into a > bitmask (e->rule.mask[word]). Not removing the x32 bit before passing > the number to this architecture independent codepath will fail to > lookup the proper audit bit. Furthermore it wi

[PATCH] x32: Mask away the x32 syscall bit in the ptrace codepath

2014-05-28 Thread Philipp Kern
audit_filter_syscall uses the syscall number to reference into a bitmask (e->rule.mask[word]). Not removing the x32 bit before passing the number to this architecture independent codepath will fail to lookup the proper audit bit. Furthermore it will cause an invalid memory access in the kernel if t