1. 04 Sep, 2017 1 commit
    • Paul Mackerras's avatar
      powerpc: Fix kernel crash in emulation of vector loads and stores · 4716e488
      Paul Mackerras authored
      Commit 350779a2 ("powerpc: Handle most loads and stores in
      instruction emulation code", 2017-08-30) changed the register usage
      in get_vr and put_vr with the aim of leaving the register number in
      r3 untouched on return.  Unfortunately, r6 was not a good choice, as
      the callers as of 350779a2 store a MSR value in r6.  Then, in
      commit c22435a5 ("powerpc: Emulate FP/vector/VSX loads/stores
      correctly when regs not live", 2017-08-30), the saving and restoring
      of the MSR got moved into get_vr and put_vr.  Either way, the effect
      is that we put a value in MSR that only has the 0x3f8 bits non-zero,
      meaning that we are switching to 32-bit mode.  That leads to a crash
      like this:
      
      Unable to handle kernel paging request for instruction fetch
      Faulting instruction address: 0x0007bea0
      Oops: Kernel access of bad area, sig: 11 [#12]
      LE SMP NR_CPUS=2048 NUMA PowerNV
      Modules linked in: vmx_crypto binfmt_misc ip_tables x_tables autofs4 crc32c_vpmsum
      CPU: 6 PID: 32659 Comm: trashy_testcase Tainted: G      D         4.13.0-rc2-00313-gf3026f57e6ed-dirty #23
      task: c000000f1bb9e780 task.stack: c000000f1ba98000
      NIP:  000000000007bea0 LR: c00000000007b054 CTR: c00000000007be70
      REGS: c000000f1ba9b960 TRAP: 0400   Tainted: G      D          (4.13.0-rc2-00313-gf3026f57e6ed-dirty)
      MSR:  10000000400010a1 <HV,ME,IR,LE>  CR: 48000228  XER: 00000000
      CFAR: c00000000007be74 SOFTE: 1
      GPR00: c00000000007b054 c000000f1ba9bbe0 c000000000e6e000 000000000000001d
      GPR04: c000000f1ba9bc00 c00000000007be70 00000000000000e8 9000000002009033
      GPR08: 0000000002000000 100000000282f033 000000000b0a0900 0000000000001009
      GPR12: 0000000000000000 c00000000fd42100 0706050303020100 a5a5a5a5a5a5a5a5
      GPR16: 2e2e2e2e2e2de70c 2e2e2e2e2e2e2e2d 0000000000ff00ff 0606040202020000
      GPR20: 000000000000005b ffffffffffffffff 0000000003020100 0000000000000000
      GPR24: c000000f1ab90020 c000000f1ba9bc00 0000000000000001 0000000000000001
      GPR28: c000000f1ba9bc90 c000000f1ba9bea0 000000000b0a0908 0000000000000001
      NIP [000000000007bea0] 0x7bea0
      LR [c00000000007b054] emulate_loadstore+0x1044/0x1280
      Call Trace:
      [c000000f1ba9bbe0] [c000000000076b80] analyse_instr+0x60/0x34f0 (unreliable)
      [c000000f1ba9bc70] [c00000000007b7ec] emulate_step+0x23c/0x544
      [c000000f1ba9bce0] [c000000000053424] arch_uprobe_skip_sstep+0x24/0x40
      [c000000f1ba9bd00] [c00000000024b2f8] uprobe_notify_resume+0x598/0xba0
      [c000000f1ba9be00] [c00000000001c284] do_notify_resume+0xd4/0xf0
      [c000000f1ba9be30] [c00000000000bd44] ret_from_except_lite+0x70/0x74
      Instruction dump:
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      ---[ end trace a7ae7a7f3e0256b5 ]---
      
      To fix this, we just revert to using r3 as before, since the callers
      don't rely on r3 being left unmodified.
      
      Fortunately, this can't be triggered by a misaligned load or store,
      because vector loads and stores truncate misaligned addresses rather
      than taking an alignment interrupt.  It can be triggered using
      uprobes.
      
      Fixes: 350779a2 ("powerpc: Handle most loads and stores in instruction emulation code")
      Reported-by: default avatarAnton Blanchard <anton@ozlabs.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Tested-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      4716e488
  2. 02 Sep, 2017 8 commits
  3. 01 Sep, 2017 31 commits