On Wed, Nov 07, 2018 at 12:44:58PM -0800, Andy Lutomirski wrote:
> > On Nov 6, 2018, at 7:27 PM, Elvira Khabirova
> > wrote:
> >
> > PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> > the tracee is blocked in. The request returns meaningful data only
> > when the tracee is in
On Wed, Nov 07, 2018 at 12:44:58PM -0800, Andy Lutomirski wrote:
> > On Nov 6, 2018, at 7:27 PM, Elvira Khabirova
> > wrote:
> >
> > PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> > the tracee is blocked in. The request returns meaningful data only
> > when the tracee is in
On 11/07, Andy Lutomirski wrote:
>
> > On Nov 7, 2018, at 8:44 AM, Oleg Nesterov wrote:
> >
> > Not sure I understand you... I do not like "compat" too, but this patch uses
> > is_compat/etc and I agree with any naming.
>
> My point is: returning a value to user code that is:
>
> 0 if the kernel
On 11/07, Andy Lutomirski wrote:
>
> > On Nov 7, 2018, at 8:44 AM, Oleg Nesterov wrote:
> >
> > Not sure I understand you... I do not like "compat" too, but this patch uses
> > is_compat/etc and I agree with any naming.
>
> My point is: returning a value to user code that is:
>
> 0 if the kernel
On 11/07, Elvira Khabirova wrote:
>
> On Wed, 7 Nov 2018 17:44:44 +0100
> Oleg Nesterov wrote:
>
> > To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
> >
> > At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can
> > clear
> > ->ptrace_message on exit if we
On 11/07, Elvira Khabirova wrote:
>
> On Wed, 7 Nov 2018 17:44:44 +0100
> Oleg Nesterov wrote:
>
> > To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
> >
> > At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can
> > clear
> > ->ptrace_message on exit if we
> On Nov 6, 2018, at 7:27 PM, Elvira Khabirova wrote:
>
> PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> the tracee is blocked in. The request returns meaningful data only
> when the tracee is in a syscall-enter-stop or a syscall-exit-stop.
>
> There are two reasons for a
> On Nov 6, 2018, at 7:27 PM, Elvira Khabirova wrote:
>
> PTRACE_GET_SYSCALL_INFO lets ptracer obtain details of the syscall
> the tracee is blocked in. The request returns meaningful data only
> when the tracee is in a syscall-enter-stop or a syscall-exit-stop.
>
> There are two reasons for a
> On Nov 7, 2018, at 8:44 AM, Oleg Nesterov wrote:
>
>> On 11/07, Andy Lutomirski wrote:
>>
>>
On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
On 11/07, Elvira Khabirova wrote:
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has
> On Nov 7, 2018, at 8:44 AM, Oleg Nesterov wrote:
>
>> On 11/07, Andy Lutomirski wrote:
>>
>>
On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
On 11/07, Elvira Khabirova wrote:
In short, if a 64-bit task performs a syscall through int 0x80, its tracer
has
On Wed, 7 Nov 2018 17:44:44 +0100
Oleg Nesterov wrote:
> To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
>
> At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can clear
> ->ptrace_message on exit if we really want PTRACE_GET_SYSCALL_INFO to fail
> after
>
On Wed, 7 Nov 2018 17:44:44 +0100
Oleg Nesterov wrote:
> To me PT_IN_SYSCALL_STOP makes no real sense, but I won't argue.
>
> At least I'd ask to not abuse task->ptrace. ptrace_report_syscall() can clear
> ->ptrace_message on exit if we really want PTRACE_GET_SYSCALL_INFO to fail
> after
>
On 11/07, Andy Lutomirski wrote:
>
>
> > On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
> >
> >> On 11/07, Elvira Khabirova wrote:
> >>
> >> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> >> has no reliable means to find out that the syscall was, in fact,
> >> a
On 11/07, Andy Lutomirski wrote:
>
>
> > On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
> >
> >> On 11/07, Elvira Khabirova wrote:
> >>
> >> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> >> has no reliable means to find out that the syscall was, in fact,
> >> a
On Wed, Nov 07, 2018 at 12:21:01PM +0100, Oleg Nesterov wrote:
> On 11/07, Elvira Khabirova wrote:
> >
> > In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> > has no reliable means to find out that the syscall was, in fact,
> > a compat syscall, and misidentifies it.
> >
On Wed, Nov 07, 2018 at 12:21:01PM +0100, Oleg Nesterov wrote:
> On 11/07, Elvira Khabirova wrote:
> >
> > In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> > has no reliable means to find out that the syscall was, in fact,
> > a compat syscall, and misidentifies it.
> >
On Wed, Nov 07, 2018 at 04:27:51AM +0100, Elvira Khabirova wrote:
[...]
> The structure was chosen according to [2], except for two changes.
> First: instead of an arch field with a value of AUDIT_ARCH_*, a boolean
> is_compat value is returned, because a) not all arches have an AUDIT_ARCH_*
>
On Wed, Nov 07, 2018 at 04:27:51AM +0100, Elvira Khabirova wrote:
[...]
> The structure was chosen according to [2], except for two changes.
> First: instead of an arch field with a value of AUDIT_ARCH_*, a boolean
> is_compat value is returned, because a) not all arches have an AUDIT_ARCH_*
>
> On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
>
>> On 11/07, Elvira Khabirova wrote:
>>
>> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
>> has no reliable means to find out that the syscall was, in fact,
>> a compat syscall, and misidentifies it.
>> *
> On Nov 7, 2018, at 3:21 AM, Oleg Nesterov wrote:
>
>> On 11/07, Elvira Khabirova wrote:
>>
>> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
>> has no reliable means to find out that the syscall was, in fact,
>> a compat syscall, and misidentifies it.
>> *
On 11/07, Elvira Khabirova wrote:
>
> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> has no reliable means to find out that the syscall was, in fact,
> a compat syscall, and misidentifies it.
> * Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
On 11/07, Elvira Khabirova wrote:
>
> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> has no reliable means to find out that the syscall was, in fact,
> a compat syscall, and misidentifies it.
> * Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
22 matches
Mail list logo
