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

Message-ID: <CAHk-=wix8-FHSpR2gebAxubQnzpgH3_HSOahh=o9TbgrPO6u0w@mail.gmail.com>
Date:   Thu, 26 Mar 2020 21:03:41 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     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 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..

              Linus