Re: [Xen-devel] backport of XSA-274 patch to 4.9.x kernel (could use a review)
> On Aug 7, 2018, at 11:49 AM, Boris Ostrovsky > wrote: > >> On 08/07/2018 01:20 PM, George Dunlap wrote: >>> On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote: >>> I just got the following patch from a colleague. It's a backport of >>> the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in >>> the XSA would not apply cleanly. Would someone mind reviewing it? It >>> would be much appreciated. >>> >>> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream. >>> >>> This version applies to v4.9. >>> >>> error_entry and error_exit communicate the user vs kernel status of >>> the frame using %ebx. This is unnecessary -- the information is in >>> regs->cs. Just use regs->cs. >>> >>> This makes error_entry simpler and makes error_exit more robust. >>> >>> It also fixes a nasty bug. Before all the Spectre nonsense, The >>> xen_failsafe_callback entry point returned like this: >>> >>>ALLOC_PT_GPREGS_ON_STACK >>>SAVE_C_REGS >>>SAVE_EXTRA_REGS >>>ENCODE_FRAME_POINTER >>>jmp error_exit >>> >>> And it did not go through error_entry. This was bogus: RBX >>> contained garbage, and error_exit expected a flag in RBX. >>> Fortunately, it generally contained *nonzero* garbage, so the >>> correct code path was used. As part of the Spectre fixes, code was >>> added to clear RBX to mitigate certain speculation attacks. Now, >>> depending on kernel configuration, RBX got zeroed and, when running >>> some Wine workloads, the kernel crashes. This was introduced by: >>> >>>commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for >>>exceptions/interrupts, to reduce speculation attack surface") >>> >>> With this patch applied, RBX is no longer needed as a flag, and the >>> problem goes away. >>> >>> Cc: Brian Gerst >>> Cc: Borislav Petkov >>> Cc: Dominik Brodowski >>> Cc: Ingo Molnar >>> Cc: "H. Peter Anvin" >>> Cc: Thomas Gleixner >>> Cc: Boris Ostrovsky >>> Cc: Juergen Gross >>> Cc: xen-devel@lists.xenproject.org >>> Cc: x...@kernel.org >>> Cc: sta...@vger.kernel.org >>> Cc: Andy Lutomirski >>> Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for >>> exceptions/interrupts, to reduce speculation attack surface") >>> Reported-and-tested-by: "M. Vefa Bicakci" >>> Signed-off-by: Sarah Newman >> I think you need to retain Andy's SoB, and add your own underneath. >> >> This looks plausible to me -- Andy / Boris, any opinions? > > > LGTM. > > Note also that Andy's patch had slightly longer commit message > (including some of the tags that you are missing), with this suggestion: > > [ Note to stable maintainers: this should probably get applied to all > kernels. If you're nervous about that, a more conservative fix to > add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should > also fix the problem. ] > On further review, I don’t like that suggestion. What if the callback came from user code. It’s not supposed to happen on modern kernels, but I’m not sure I trust that. > > > > -boris > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] backport of XSA-274 patch to 4.9.x kernel (could use a review)
On 08/07/2018 01:20 PM, George Dunlap wrote: > On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote: >> I just got the following patch from a colleague. It's a backport of >> the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in >> the XSA would not apply cleanly. Would someone mind reviewing it? It >> would be much appreciated. >> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream. >> >> This version applies to v4.9. >> >> error_entry and error_exit communicate the user vs kernel status of >> the frame using %ebx. This is unnecessary -- the information is in >> regs->cs. Just use regs->cs. >> >> This makes error_entry simpler and makes error_exit more robust. >> >> It also fixes a nasty bug. Before all the Spectre nonsense, The >> xen_failsafe_callback entry point returned like this: >> >> ALLOC_PT_GPREGS_ON_STACK >> SAVE_C_REGS >> SAVE_EXTRA_REGS >> ENCODE_FRAME_POINTER >> jmp error_exit >> >> And it did not go through error_entry. This was bogus: RBX >> contained garbage, and error_exit expected a flag in RBX. >> Fortunately, it generally contained *nonzero* garbage, so the >> correct code path was used. As part of the Spectre fixes, code was >> added to clear RBX to mitigate certain speculation attacks. Now, >> depending on kernel configuration, RBX got zeroed and, when running >> some Wine workloads, the kernel crashes. This was introduced by: >> >> commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for >> exceptions/interrupts, to reduce speculation attack surface") >> >> With this patch applied, RBX is no longer needed as a flag, and the >> problem goes away. >> >> Cc: Brian Gerst >> Cc: Borislav Petkov >> Cc: Dominik Brodowski >> Cc: Ingo Molnar >> Cc: "H. Peter Anvin" >> Cc: Thomas Gleixner >> Cc: Boris Ostrovsky >> Cc: Juergen Gross >> Cc: xen-devel@lists.xenproject.org >> Cc: x...@kernel.org >> Cc: sta...@vger.kernel.org >> Cc: Andy Lutomirski >> Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for >> exceptions/interrupts, to reduce speculation attack surface") >> Reported-and-tested-by: "M. Vefa Bicakci" >> Signed-off-by: Sarah Newman > I think you need to retain Andy's SoB, and add your own underneath. > > This looks plausible to me -- Andy / Boris, any opinions? LGTM. Note also that Andy's patch had slightly longer commit message (including some of the tags that you are missing), with this suggestion: [ Note to stable maintainers: this should probably get applied to all kernels. If you're nervous about that, a more conservative fix to add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should also fix the problem. ] -boris ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] backport of XSA-274 patch to 4.9.x kernel (could use a review)
On Mon, Aug 6, 2018 at 8:10 PM, Chris Brannon wrote: > I just got the following patch from a colleague. It's a backport of > the XSA 274 kernel patch to 4.9.x kernels. The kernel patch given in > the XSA would not apply cleanly. Would someone mind reviewing it? It > would be much appreciated. > > commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream. > > This version applies to v4.9. > > error_entry and error_exit communicate the user vs kernel status of > the frame using %ebx. This is unnecessary -- the information is in > regs->cs. Just use regs->cs. > > This makes error_entry simpler and makes error_exit more robust. > > It also fixes a nasty bug. Before all the Spectre nonsense, The > xen_failsafe_callback entry point returned like this: > > ALLOC_PT_GPREGS_ON_STACK > SAVE_C_REGS > SAVE_EXTRA_REGS > ENCODE_FRAME_POINTER > jmp error_exit > > And it did not go through error_entry. This was bogus: RBX > contained garbage, and error_exit expected a flag in RBX. > Fortunately, it generally contained *nonzero* garbage, so the > correct code path was used. As part of the Spectre fixes, code was > added to clear RBX to mitigate certain speculation attacks. Now, > depending on kernel configuration, RBX got zeroed and, when running > some Wine workloads, the kernel crashes. This was introduced by: > > commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for > exceptions/interrupts, to reduce speculation attack surface") > > With this patch applied, RBX is no longer needed as a flag, and the > problem goes away. > > Cc: Brian Gerst > Cc: Borislav Petkov > Cc: Dominik Brodowski > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Thomas Gleixner > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: xen-devel@lists.xenproject.org > Cc: x...@kernel.org > Cc: sta...@vger.kernel.org > Cc: Andy Lutomirski > Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for > exceptions/interrupts, to reduce speculation attack surface") > Reported-and-tested-by: "M. Vefa Bicakci" > Signed-off-by: Sarah Newman I think you need to retain Andy's SoB, and add your own underneath. This looks plausible to me -- Andy / Boris, any opinions? -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel