linux-kernel - Re: syscall_get_error() && TS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Mar 2017 11:23:15 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Jan Kratochvil <jan.kratochvil@...hat.com>,
        Pedro Alves <palves@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: syscall_get_error() && TS_ checks

On Thu, Mar 30, 2017 at 10:46 AM, Linus Torvalds
<torvalds@...ux-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