Messages in this thread | | | Date | Wed, 18 Dec 2019 16:54:49 +0100 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH v2 3/3] x86/fpu/xstate: Invalidate fpregs when __fpu_restore_sig() fails |
| |
On 2019-12-12 13:08:55 [-0800], Yu-cheng Yu wrote: > In __fpu_restore_sig(),'init_fpstate.xsave' and part of 'fpu->state.xsave' > are restored separately to xregs. However, as stated in __cpu_invalidate_ > fpregs_state(), > > Any code that clobbers the FPU registers or updates the in-memory > FPU state for a task MUST let the rest of the kernel know that the > FPU registers are no longer valid for this task. > > and this code violates that rule. Should the restoration fail, the other > task's context is corrupted. > > This problem does not occur very often because copy_*_to_xregs() succeeds > most of the time.
why "most of the time"? It should always succeed. We talk here about __fpu__restore_sig() correct? Using init_fpstate as part of restore process isn't the "default" case. If the restore _here_ fails then it fails.
> It occurs, for instance, in copy_user_to_fpregs_ > zeroing() when the first half of the restoration succeeds and the other > half fails. This can be triggered by running glibc tests, where a non- > present user stack page causes the XRSTOR to fail.
So if copy_user_to_fpregs_zeroing() fails then we go to the slowpath. Then we load the FPU register with copy_kernel_to_xregs_err(). In the end they are either enabled (fpregs_mark_activate()) or cleared if it failed (fpu__clear()). Don't see here a problem.
Can you tell me which glibc test? I would like to reproduce this.
> The introduction of supervisor xstates and CET, while not contributing to > the problem, makes it more detectable. After init_fpstate and the Shadow > Stack pointer have been restored to xregs, the XRSTOR from user stack > fails and fpu_fpregs_owner_ctx is not updated. The task currently owning > fpregs then uses the corrupted Shadow Stack pointer and triggers a control- > protection fault.
So I don't need new HW with supervisor and CET? A plain KVM box with SSE2 and so should be enough?
Sebastian
| |