On Tue, Aug 12, 2014 at 12:17:53PM +0100, AKASHI Takahiro wrote:
> On 08/12/2014 06:40 PM, Will Deacon wrote:
> > On Tue, Aug 12, 2014 at 07:57:25AM +0100, AKASHI Takahiro wrote:
> >>
> >> > case SECCOMP_MODE_FILTER:
> >> > case SECCOMP_RET_TRACE:
> >> > ...
> >> >
On 08/12/2014 06:40 PM, Will Deacon wrote:
Hi Akashi,
On Tue, Aug 12, 2014 at 07:57:25AM +0100, AKASHI Takahiro wrote:
On 08/11/2014 06:24 PM, Will Deacon wrote:
On Fri, Aug 08, 2014 at 08:35:42AM +0100, AKASHI Takahiro wrote:
As discussed in a few weeks ago, aarch64 won't support PTRACE_SET_
Hi Akashi,
On Tue, Aug 12, 2014 at 07:57:25AM +0100, AKASHI Takahiro wrote:
> On 08/11/2014 06:24 PM, Will Deacon wrote:
> > On Fri, Aug 08, 2014 at 08:35:42AM +0100, AKASHI Takahiro wrote:
> >> As discussed in a few weeks ago, aarch64 won't support PTRACE_SET_SYSCALL.
> >
> > Well, I don't think
Will,
On 08/11/2014 06:24 PM, Will Deacon wrote:
On Fri, Aug 08, 2014 at 08:35:42AM +0100, AKASHI Takahiro wrote:
On 08/06/2014 12:08 AM, Kees Cook wrote:
On Fri, Jul 25, 2014 at 2:37 AM, AKASHI Takahiro
wrote:
I found a bug in my current patch (v5). When 32-bit tracer skips a system call,
w
On Fri, Aug 08, 2014 at 08:35:42AM +0100, AKASHI Takahiro wrote:
> On 08/06/2014 12:08 AM, Kees Cook wrote:
> > On Fri, Jul 25, 2014 at 2:37 AM, AKASHI Takahiro
> > wrote:
> >> I found a bug in my current patch (v5). When 32-bit tracer skips a system
> >> call,
> >> we should not update syscallno
On 08/06/2014 12:08 AM, Kees Cook wrote:
On Fri, Jul 25, 2014 at 2:37 AM, AKASHI Takahiro
wrote:
I found a bug in my current patch (v5). When 32-bit tracer skips a system call,
we should not update syscallno from x8 since syscallno is re-written directly
via ptrace(PTRACE_SET_SYSCALL).
Ah, ye
On Fri, Jul 25, 2014 at 2:37 AM, AKASHI Takahiro
wrote:
> I found a bug in my current patch (v5). When 32-bit tracer skips a system
> call,
> we should not update syscallno from x8 since syscallno is re-written directly
> via ptrace(PTRACE_SET_SYSCALL).
Ah, yes. Will aarch64 have a PTRACE_SET_SY
On 07/25/2014 12:00 AM, Andy Lutomirski wrote:
On Jul 23, 2014 10:40 PM, "AKASHI Takahiro" wrote:
On 07/24/2014 12:52 PM, Andy Lutomirski wrote:
On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
secure_computing() should always be called first in syscall_trace_enter().
If secure_computing()
On Thu, Jul 24, 2014 at 04:00:03PM +0100, Andy Lutomirski wrote:
> On Jul 23, 2014 10:40 PM, "AKASHI Takahiro"
> wrote:
> > when I implemented audit for arm64, the assumptions were
> > * If userspace is LE, then the kernel is also LE and if BE, then the kernel
> > is BE.
> > * the syscall number
On Jul 23, 2014 10:40 PM, "AKASHI Takahiro" wrote:
>
> On 07/24/2014 12:52 PM, Andy Lutomirski wrote:
>>
>> On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
>>>
>>> secure_computing() should always be called first in syscall_trace_enter().
>>>
>>> If secure_computing() returns -1, we should stop fur
On 07/24/2014 12:52 PM, Andy Lutomirski wrote:
On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
secure_computing() should always be called first in syscall_trace_enter().
If secure_computing() returns -1, we should stop further handling. Then
that system call may eventually fail with a specified
On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
secure_computing() should always be called first in syscall_trace_enter().
If secure_computing() returns -1, we should stop further handling. Then
that system call may eventually fail with a specified return value (errno),
be trapped or the process
secure_computing() should always be called first in syscall_trace_enter().
If secure_computing() returns -1, we should stop further handling. Then
that system call may eventually fail with a specified return value (errno),
be trapped or the process itself be killed depending on loaded rules.
In th
13 matches
Mail list logo