[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160317113740.GB28772@pd.tnic>
Date: Thu, 17 Mar 2016 12:37:40 +0100
From: Borislav Petkov <bp@...en8.de>
To: Andy Lutomirski <luto@...capital.net>
Cc: linux-tip-commits@...r.kernel.org, luto@...nel.org,
peterz@...radead.org, dvlasenk@...hat.com, luto@...capital.net,
brgerst@...il.com, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, david.vrabel@...rix.com,
JBeulich@...e.com, torvalds@...ux-foundation.org, hpa@...or.com,
tglx@...utronix.de, boris.ostrovsky@...cle.com, mingo@...nel.org
Subject: Re: [tip:x86/urgent] x86/iopl/64: Properly context-switch IOPL on
Xen PV
On Thu, Mar 17, 2016 at 02:19:12AM -0700, tip-bot for Andy Lutomirski wrote:
> Commit-ID: b7a584598aea7ca73140cb87b40319944dd3393f
> Gitweb: http://git.kernel.org/tip/b7a584598aea7ca73140cb87b40319944dd3393f
> Author: Andy Lutomirski <luto@...nel.org>
> AuthorDate: Wed, 16 Mar 2016 14:14:21 -0700
> Committer: Ingo Molnar <mingo@...nel.org>
> CommitDate: Thu, 17 Mar 2016 09:49:26 +0100
>
> x86/iopl/64: Properly context-switch IOPL on Xen PV
>
> On Xen PV, regs->flags doesn't reliably reflect IOPL and the
> exit-to-userspace code doesn't change IOPL. We need to context
> switch it manually.
>
> I'm doing this without going through paravirt because this is
> specific to Xen PV. After the dust settles, we can merge this with
> the 32-bit code, tidy up the iopl syscall implementation, and remove
> the set_iopl pvop entirely.
>
> Fixes XSA-171.
>
> Reviewewd-by: Jan Beulich <JBeulich@...e.com>
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> Cc: Andrew Cooper <andrew.cooper3@...rix.com>
> Cc: Andy Lutomirski <luto@...capital.net>
> Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: David Vrabel <david.vrabel@...rix.com>
> Cc: Denys Vlasenko <dvlasenk@...hat.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Jan Beulich <JBeulich@...e.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: stable@...r.kernel.org
> Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> ---
> arch/x86/include/asm/xen/hypervisor.h | 2 ++
> arch/x86/kernel/process_64.c | 12 ++++++++++++
> arch/x86/xen/enlighten.c | 2 +-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/xen/hypervisor.h b/arch/x86/include/asm/xen/hypervisor.h
> index 8b2d4be..39171b3 100644
> --- a/arch/x86/include/asm/xen/hypervisor.h
> +++ b/arch/x86/include/asm/xen/hypervisor.h
> @@ -62,4 +62,6 @@ void xen_arch_register_cpu(int num);
> void xen_arch_unregister_cpu(int num);
> #endif
>
> +extern void xen_set_iopl_mask(unsigned mask);
> +
> #endif /* _ASM_X86_XEN_HYPERVISOR_H */
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index b9d99e0..9f75187 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -48,6 +48,7 @@
> #include <asm/syscalls.h>
> #include <asm/debugreg.h>
> #include <asm/switch_to.h>
> +#include <asm/xen/hypervisor.h>
>
> asmlinkage extern void ret_from_fork(void);
>
> @@ -411,6 +412,17 @@ __switch_to(struct task_struct *prev_p, struct task_struct *next_p)
> task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
> __switch_to_xtra(prev_p, next_p, tss);
>
> +#ifdef CONFIG_XEN
> + /*
> + * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
> + * current_pt_regs()->flags may not match the current task's
> + * intended IOPL. We need to switch it manually.
> + */
> + if (unlikely(static_cpu_has(X86_FEATURE_XENPV) &&
> + prev->iopl != next->iopl))
> + xen_set_iopl_mask(next->iopl);
> +#endif
I'm wondering if it would've been cleaner if this was a
arch_fixup_iopl_mask() defined in arch/x86/xen/enlighten.c and a stub
otherwise.
This would save you the ifdeffery and the export of
xen_set_iopl_mask()...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Powered by blists - more mailing lists