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
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
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
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
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
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 fail
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
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
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
10 matches
Mail list logo