1. 08 Feb, 2020 2 commits
    • Christophe Leroy's avatar
      powerpc: Fix CONFIG_TRACE_IRQFLAGS with CONFIG_VMAP_STACK · d4bf9053
      Christophe Leroy authored
      When CONFIG_PROVE_LOCKING is selected together with (now default)
      CONFIG_VMAP_STACK, kernel enter deadlock during boot.
      
      At the point of checking whether interrupts are enabled or not, the
      value of MSR saved on stack is read using the physical address of the
      stack. But at this point, when using VMAP stack the DATA MMU
      translation has already been re-enabled, leading to deadlock.
      
      Don't use the physical address of the stack when
      CONFIG_VMAP_STACK is set.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Fixes: 02847487 ("powerpc/32: prepare for CONFIG_VMAP_STACK")
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/daeacdc0dec0416d1c587cc9f9e7191ad3068dc0.1581095957.git.christophe.leroy@c-s.fr
      d4bf9053
    • Michael Ellerman's avatar
      powerpc/futex: Fix incorrect user access blocking · 9dc086f1
      Michael Ellerman authored
      The early versions of our kernel user access prevention (KUAP) were
      written by Russell and Christophe, and didn't have separate
      read/write access.
      
      At some point I picked up the series and added the read/write access,
      but I failed to update the usages in futex.h to correctly allow read
      and write.
      
      However we didn't notice because of another bug which was causing the
      low-level code to always enable read and write. That bug was fixed
      recently in commit 1d8f739b ("powerpc/kuap: Fix set direction in
      allow/prevent_user_access()").
      
      futex_atomic_cmpxchg_inatomic() is passed the user address as %3 and
      does:
      
        1:     lwarx   %1,  0, %3
               cmpw    0,  %1, %4
               bne-    3f
        2:     stwcx.  %5,  0, %3
      
      Which clearly loads and stores from/to %3. The logic in
      arch_futex_atomic_op_inuser() is similar, so fix both of them to use
      allow_read_write_user().
      
      Without this fix, and with PPC_KUAP_DEBUG=y, we see eg:
      
        Bug: Read fault blocked by AMR!
        WARNING: CPU: 94 PID: 149215 at arch/powerpc/include/asm/book3s/64/kup-radix.h:126 __do_page_fault+0x600/0xf30
        CPU: 94 PID: 149215 Comm: futex_requeue_p Tainted: G        W         5.5.0-rc7-gcc9x-g4c25df56 #1
        ...
        NIP [c000000000070680] __do_page_fault+0x600/0xf30
        LR [c00000000007067c] __do_page_fault+0x5fc/0xf30
        Call Trace:
        [c00020138e5637e0] [c00000000007067c] __do_page_fault+0x5fc/0xf30 (unreliable)
        [c00020138e5638c0] [c00000000000ada8] handle_page_fault+0x10/0x30
        --- interrupt: 301 at cmpxchg_futex_value_locked+0x68/0xd0
            LR = futex_lock_pi_atomic+0xe0/0x1f0
        [c00020138e563bc0] [c000000000217b50] futex_lock_pi_atomic+0x80/0x1f0 (unreliable)
        [c00020138e563c30] [c00000000021b668] futex_requeue+0x438/0xb60
        [c00020138e563d60] [c00000000021c6cc] do_futex+0x1ec/0x2b0
        [c00020138e563d90] [c00000000021c8b8] sys_futex+0x128/0x200
        [c00020138e563e20] [c00000000000b7ac] system_call+0x5c/0x68
      
      Fixes: de78a9c4 ("powerpc: Add a framework for Kernel Userspace Access Protection")
      Cc: stable@vger.kernel.org # v5.2+
      Reported-by: syzbot+e808452bad7c375cbee6@syzkaller-ppc64.appspotmail.com
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Link: https://lore.kernel.org/r/20200207122145.11928-1-mpe@ellerman.id.au
      9dc086f1
  2. 04 Feb, 2020 38 commits