Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, Jun 20, 2016 at 9:14 AM, Oleg Nesterov wrote: > On 06/20, Andy Lutomirski wrote: >> >> On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: >> > >> > How about the simple change below for now? IIRC 32-bit task can't use >> > "syscall" so if

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, Jun 20, 2016 at 9:14 AM, Oleg Nesterov wrote: > On 06/20, Andy Lutomirski wrote: >> >> On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: >> > >> > How about the simple change below for now? IIRC 32-bit task can't use >> > "syscall" so if syscall_get_nr() >= 0 then even the wrong

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/20, Andy Lutomirski wrote: > > On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: > > > > How about the simple change below for now? IIRC 32-bit task can't use > > "syscall" so if syscall_get_nr() >= 0 then even the wrong TS_COMPAT is > > not that bad, even if it "leaks"

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/20, Andy Lutomirski wrote: > > On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: > > > > How about the simple change below for now? IIRC 32-bit task can't use > > "syscall" so if syscall_get_nr() >= 0 then even the wrong TS_COMPAT is > > not that bad, even if it "leaks" to user-mode. >

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: > On 06/19, Andy Lutomirski wrote: >> >> On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski >> wrote: >> Step 1: for 4.7 and for -stable, introduce TS_I386_REGS_POKED. Set it >> in putreg32. Use it in

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, Jun 20, 2016 at 8:24 AM, Oleg Nesterov wrote: > On 06/19, Andy Lutomirski wrote: >> >> On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski >> wrote: >> Step 1: for 4.7 and for -stable, introduce TS_I386_REGS_POKED. Set it >> in putreg32. Use it in syscall_get_error,

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19, Andy Lutomirski wrote: > > On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > Step 1: for 4.7 and for -stable, introduce TS_I386_REGS_POKED. Set it > in putreg32. Use it in syscall_get_error, get_nr_restart_syscall, > etc. Clear it in do_signal.

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19, Andy Lutomirski wrote: > > On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > Step 1: for 4.7 and for -stable, introduce TS_I386_REGS_POKED. Set it > in putreg32. Use it in syscall_get_error, get_nr_restart_syscall, > etc. Clear it in do_signal. do_signal() won't be

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19, Andy Lutomirski wrote: > > On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > > > > And this leads to another question, why do we actually need to set/clear > > TS_COMPAT in set_personality_ia32() ?? > > Something's clearly buggy there, considering that >

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19, Andy Lutomirski wrote: > > On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > > > > And this leads to another question, why do we actually need to set/clear > > TS_COMPAT in set_personality_ia32() ?? > > Something's clearly buggy there, considering that > set_personality_64bit()

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, 20 Jun 2016 12:07:56 +0200, Pedro Alves wrote: > On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > > Yuck. I should have dug in to the history. Why not just > > unconditionally sign-extend eax when set by a 32-bit tracer? > > No idea. Roland McGrath knows why he wrote it that way, Cced.

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Mon, 20 Jun 2016 12:07:56 +0200, Pedro Alves wrote: > On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > > Yuck. I should have dug in to the history. Why not just > > unconditionally sign-extend eax when set by a 32-bit tracer? > > No idea. Roland McGrath knows why he wrote it that way, Cced.

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19/2016 11:09 PM, Andy Lutomirski wrote: > > The latter bit is a mess and is probably broken on current kernels for > 64-bit gdb attached to a 32-bit process. (Is it? All of this stuff > is a bit of a pain to test.) The testcase at: https://sourceware.org/ml/gdb/2014-05/msg4.html

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/19/2016 11:09 PM, Andy Lutomirski wrote: > > The latter bit is a mess and is probably broken on current kernels for > 64-bit gdb attached to a 32-bit process. (Is it? All of this stuff > is a bit of a pain to test.) The testcase at: https://sourceware.org/ml/gdb/2014-05/msg4.html

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > Yuck. I should have dug in to the history. Why not just > unconditionally sign-extend eax when set by a 32-bit tracer? No idea. > > Do you know how to acquire a copy of erestartsys-trap.c? The old > links appear to be broken. That's part of

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 06:02 PM, Andy Lutomirski wrote: > Yuck. I should have dug in to the history. Why not just > unconditionally sign-extend eax when set by a 32-bit tracer? No idea. > > Do you know how to acquire a copy of erestartsys-trap.c? The old > links appear to be broken. That's part of

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now I have nothing to

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sun, Jun 19, 2016 at 2:19 PM, Oleg Nesterov wrote: > Let me first thank Pedro who has already replied! > > And I have to admit I will need to re-read his explanations after > sleep to (try to) convince myself I fully understans the problems ;) > Too late for me. > > Right now I have nothing to

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

Let me first thank Pedro who has already replied! And I have to admit I will need to re-read his explanations after sleep to (try to) convince myself I fully understans the problems ;) Too late for me. Right now I have nothing to add, but On 06/18, Andy Lutomirski wrote: > > @@ -922,16 +922,7

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

Let me first thank Pedro who has already replied! And I have to admit I will need to re-read his explanations after sleep to (try to) convince myself I fully understans the problems ;) Too late for me. Right now I have nothing to add, but On 06/18, Andy Lutomirski wrote: > > @@ -922,16 +922,7

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: >> >> On 06/18/2016 11:21 AM, Andy Lutomirski wrote: >> > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. >> > >> > - If the tracee

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 10:02 AM, Andy Lutomirski wrote: > On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: >> >> On 06/18/2016 11:21 AM, Andy Lutomirski wrote: >> > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. >> > >> > - If the tracee is stopped in a 32-bit syscall, this

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski wrote: > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > - If the tracee is stopped in a 32-bit syscall, this has no effect > as TS_COMPAT will already be set. > > - If the tracee is stopped on entry to a

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Sat, Jun 18, 2016 at 3:21 AM, Andy Lutomirski wrote: > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > - If the tracee is stopped in a 32-bit syscall, this has no effect > as TS_COMPAT will already be set. > > - If the tracee is stopped on entry to a 64-bit syscall,

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: > > On 06/18/2016 11:21 AM, Andy Lutomirski wrote: > > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > > > - If the tracee is stopped in a 32-bit syscall, this has no effect > > as TS_COMPAT will already be

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On Jun 18, 2016 6:56 AM, "Pedro Alves" wrote: > > On 06/18/2016 11:21 AM, Andy Lutomirski wrote: > > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > > > - If the tracee is stopped in a 32-bit syscall, this has no effect > > as TS_COMPAT will already be set. > > > > - If

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 02:55 PM, Pedro Alves wrote: > This hunk being mentioned in this thread a couple years ago too: > > https://www.sourceware.org/ml/gdb/2014-04/msg00095.html > > Please don't break this use case ( and fix the one reported in > that thread :-) ). BTW, there was a follow up v2 patch

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 02:55 PM, Pedro Alves wrote: > This hunk being mentioned in this thread a couple years ago too: > > https://www.sourceware.org/ml/gdb/2014-04/msg00095.html > > Please don't break this use case ( and fix the one reported in > that thread :-) ). BTW, there was a follow up v2 patch

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 11:21 AM, Andy Lutomirski wrote: > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > - If the tracee is stopped in a 32-bit syscall, this has no effect > as TS_COMPAT will already be set. > > - If the tracee is stopped on entry to a 64-bit syscall, this

Re: [PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

On 06/18/2016 11:21 AM, Andy Lutomirski wrote: > A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. > > - If the tracee is stopped in a 32-bit syscall, this has no effect > as TS_COMPAT will already be set. > > - If the tracee is stopped on entry to a 64-bit syscall, this

[PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. - If the tracee is stopped in a 32-bit syscall, this has no effect as TS_COMPAT will already be set. - If the tracee is stopped on entry to a 64-bit syscall, this could cause problems: in_compat_syscall() etc will be out of

[PATCH] x86/ptrace: Remove questionable TS_COMPAT usage in ptrace

A 32-bit tracer can set a tracee's TS_COMPAT flag by poking orig_ax. - If the tracee is stopped in a 32-bit syscall, this has no effect as TS_COMPAT will already be set. - If the tracee is stopped on entry to a 64-bit syscall, this could cause problems: in_compat_syscall() etc will be out of