linux-kernel - Re: x86 entry perf unwinding failure (missing IRET

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:   Mon, 2 Mar 2020 09:18:29 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: x86 entry perf unwinding failure (missing IRET_REGS annotation
 on stack switch?)

On Sun, Mar 01, 2020 at 07:02:15AM +0100, Jann Horn wrote:
> It looks to me like things go wrong at the point where we switch over
> to the trampoline stack? The ORC info claims that we have full user
> registers on the trampoline stack (and that we're clobbering them with
> our pushes - apparently objtool is not smart enough to realize that
> that looks bogus), but at that point we should probably actually use
> something like UNWIND_HINT_IRET_REGS, right?

Good timing.  I have a patch set coming in a few days which fixes
several ORC issues, and this was one of them.

> By the way, looking through the rest of the entry stuff, there's some
> other funny-looking stuff, too:
> 
> ============
> 0000000000000f40 <general_protection>:
> #######sp:sp+8 bp:(und) type:iret end:0
>      f40:       90                      nop
> #######sp:(und) bp:(und) type:call end:0
>      f41:       90                      nop
>      f42:       90                      nop
> #######sp:sp+8 bp:(und) type:iret end:0
>      f43:       e8 a8 01 00 00          callq  10f0 <error_entry>
> #######sp:sp+0 bp:(und) type:regs end:0
>      f48:       f6 84 24 88 00 00 00    testb  $0x3,0x88(%rsp)
>      f4f:       03
>      f50:       74 00                   je     f52 <general_protection+0x12>
>      f52:       48 89 e7                mov    %rsp,%rdi
>      f55:       48 8b 74 24 78          mov    0x78(%rsp),%rsi
>      f5a:       48 c7 44 24 78 ff ff    movq   $0xffffffffffffffff,0x78(%rsp)
>      f61:       ff ff
>      f63:       e8 00 00 00 00          callq  f68 <general_protection+0x28>
>      f68:       e9 73 02 00 00          jmpq   11e0 <error_exit>
> #######sp:(und) bp:(und) type:call end:0
>      f6d:       0f 1f 00                nopl   (%rax)
> ============
> 
> So I think on machines without X86_FEATURE_SMAP, trying to unwind from
> the two NOPs at f41 and f42 will cause the unwinder to report an
> error? Looking at unwind_next_frame(), "sp:(und)" without the "end:1"
> marker seems to be reserved for errors.

Hm... good catch.  Not sure why objtool is doing that but I'll look into
it.

-- 
Josh