• Timothy Pearson's avatar
    powerpc: Don't clobber f0/vs0 during fp|altivec register save · 5e1d824f
    Timothy Pearson authored
    During floating point and vector save to thread data f0/vs0 are
    clobbered by the FPSCR/VSCR store routine. This has been obvserved to
    lead to userspace register corruption and application data corruption
    with io-uring.
    
    Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
    all the FP, altivec, VMX register save paths.
    
    Tested under QEMU in kvm mode, running on a Talos II workstation with
    dual POWER9 DD2.2 CPUs.
    
    Additional detail (mpe):
    
    Typically save_fpu() is called from __giveup_fpu() which saves the FP
    regs and also *turns off FP* in the tasks MSR, meaning the kernel will
    reload the FP regs from the thread struct before letting the task use FP
    again. So in that case save_fpu() is free to clobber f0 because the FP
    regs no longer hold live values for the task.
    
    There is another case though, which is the path via:
      sys_clone()
        ...
        copy_process()
          dup_task_struct()
            arch_dup_task_struct()
              flush_all_to_thread()
                save_all()
    
    That path saves the FP regs but leaves them live. That's meant as an
    optimisation for a process that's using FP/VSX and then calls fork(),
    leaving the regs live means the parent process doesn't have to take a
    fault after the fork to get its FP regs back. The optimisation was added
    in commit 8792468d ("powerpc: Add the ability to save FPU without
    giving it up").
    
    That path does clobber f0, but f0 is volatile across function calls,
    and typically programs reach copy_process() from userspace via a syscall
    wrapper function. So in normal usage f0 being clobbered across a
    syscall doesn't cause visible data corruption.
    
    But there is now a new path, because io-uring can call copy_process()
    via create_io_thread() from the signal handling path. That's OK if the
    signal is handled as part of syscall return, but it's not OK if the
    signal is handled due to some other interrupt.
    
    That path is:
    
    interrupt_return_srr_user()
      interrupt_exit_user_prepare()
        interrupt_exit_user_prepare_main()
          do_notify_resume()
            get_signal()
              task_work_run()
                create_worker_cb()
                  create_io_worker()
                    copy_process()
                      dup_task_struct()
                        arch_dup_task_struct()
                          flush_all_to_thread()
                            save_all()
                              if (tsk->thread.regs->msr & MSR_FP)
                                save_fpu()
                                # f0 is clobbered and potentially live in userspace
    
    Note the above discussion applies equally to save_altivec().
    
    Fixes: 8792468d ("powerpc: Add the ability to save FPU without giving it up")
    Cc: stable@vger.kernel.org # v4.6+
    Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
    Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/Tested-by: default avatarTimothy Pearson <tpearson@raptorengineering.com>
    Tested-by: default avatarJens Axboe <axboe@kernel.dk>
    Signed-off-by: default avatarTimothy Pearson <tpearson@raptorengineering.com>
    [mpe: Reword change log to describe exact path of corruption & other minor tweaks]
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
    5e1d824f
fpu.S 3.99 KB