linux-kernel - Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access

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] [day] [month] [year] [list]

Message-ID: <20200327043542.nuvxllamanwigtzo@treble>
Date:   Thu, 26 Mar 2020 23:35:42 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 5/7] x86: convert arch_futex_atomic_op_inuser() to
 user_access_begin/user_access_end()

On Thu, Mar 26, 2020 at 09:03:41PM -0700, Linus Torvalds wrote:
> On Thu, Mar 26, 2020 at 8:49 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Seems to work for me.
> >
> > That's with the futex bug fixed. Not that it looks like it would have
> > mattered except for the (unlikely) exception case, so my testing is
> > meaningless.
> 
> Hmm. Doing a "perf" run, I only noticed after-the-fact that I got this:
> 
>   WARNING: stack recursion on stack type 4
>   WARNING: can't dereference registers at 0000000079a3d9c5 for ip
> swapgs_restore_regs_and_return_to_usermode+0x25/0x80
> 
> that may not be due to any of the uaccess or futex changes, though, it
> smells like just bad luck.
> 
> Josh?
> 
> This may also be related to the fact that I've been building my
> test-boot kernels with clang for the last couple of months,
> 
> That "swapgs_restore_regs_and_return_to_usermode+0x25" location is the
> 
>         pushq  0x28(%rdi)
> 
> instruction. That's this:
> 
>         movq    %rsp, %rdi
>         movq    PER_CPU_VAR(cpu_tss_rw + TSS_sp0), %rsp
> 
>         /* Copy the IRET frame to the trampoline stack. */
>         pushq   6*8(%rdi)       /* SS */
> --->    pushq   5*8(%rdi)       /* RSP */
>         pushq   4*8(%rdi)       /* EFLAGS */
>         pushq   3*8(%rdi)       /* CS */
>         pushq   2*8(%rdi)       /* RIP */
> 
> and yeah, at this point the stack is obviously a mess, so I'm not
> surprised that it might cause confusion for unwinding..

You did indeed get unlucky, and that's the correct diagnosis.  It's
pretty harmless.

  https://lkml.kernel.org/r/58c05bf0a9f06ac7f2ed6df5e369d3276ccec33c.1584033751.git.jpoimboe@redhat.com

Working on a v2, I'll add you to the already excessive Reported-by list
:-)

-- 
Josh