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
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 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
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
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
>
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
>>>
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
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
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
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
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 will
On Wed, May 28, 2014 at 10:47 PM, Andy Lutomirski l...@amacapital.net 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
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 to
On Wed, May 28, 2014 at 2:01 PM, H. Peter Anvin h...@linux.intel.com 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
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
seccomp users.
On Wed, May 28, 2014 at 2:19 PM, H. Peter Anvin h...@linux.intel.com 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
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net 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
On Wed, May 28, 2014 at 2:53 PM, Philipp Kern pk...@google.com wrote:
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net 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
On 05/28/2014 02:53 PM, Philipp Kern wrote:
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net 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
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
20 matches
Mail list logo
