On Thu, Mar 30, 2017 at 10:46 AM, Linus Torvalds
<torva...@linux-foundation.org> wrote:
> For example, let's assume that %eax contains a 32-bit pointer with the
> high bit set, and we're using a 32-bit debugger on a 32-bit program
> (ie you're just running a 32-bit distro on a 64-bit kernel, which
> people have definitely done).
>
> We *really* shouldn't sign-extend that value if the debugger ends up
> updating the pointer (or maybe the debugger just reloads previous
> values, not really "updating" anything - I think that's what gdb does
> when you do a call within the context of the debugged program from
> within gdb, for example)
Can you think of a case where this would actually matter?
>
> So I really *really* don't think you can just sign-extend %eax. Which
> is exactly why we have that nasty odd sign-extension in the signal
> path instead, but then have to make it conditional on running a 32-bit
> program.
>
> But maybe there is still something I'm not understanding in your
> argument. This thread has been a series of mis-understandings.
As the daft kernel hacker who introduced TS_I386_REGS_POKED in the
first place, I'll try to explain what I think is going on.
TS_I386_REGS_POKED is an enormous kludge, and it serves two purposes.
It avoids a potential security bug that the old code had, and it at
least documents the code paths that are thoroughly broken. (Before
they were TS_COMPAT instead, but most of the TS_COMPAT users are
fine.)
It's used in two places:
--- issue 1 ---
get_nr_restart_syscall() does:
if (current->thread.status & (TS_COMPAT|TS_I386_REGS_POKED))
return __NR_ia32_restart_syscall;
This is very, very buggy. Fixing this appears to require somewhat
some surgery. Proposals include adding new restart_syscall numbers
that match across 32-bit and 64-bit (interacts quite awkwardly with
seccomp) or trying to store syscall bitness along with restart_block
(ick, not actually 100% reliable depending on just how abusing the
debugger is).
--- issue 2 ---
syscall_get_error(). This is available on all arches, but it appears
to be used *only* on x86. It's used to figure out whether we're
restarting a syscall. It could plausibly matter if we have a buggy
compat syscall that returns int instead of long, but the main purpose
is for compatibility with 32-bit debuggers.
Neither Oleg nor I have thought of anything other than this code path
that cares at all about the high bits of RAX on a process that's being
poked using 32-bit ptrace. Sign-extending RAX seems like it would get
rid of this code path entirely to me.
--Andy
