From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751467AbeACWXC (ORCPT + 1 other); Wed, 3 Jan 2018 17:23:02 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:40730 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbeACWXB (ORCPT ); Wed, 3 Jan 2018 17:23:01 -0500 Date: Wed, 3 Jan 2018 23:22:57 +0100 (CET) From: Thomas Gleixner To: Andy Lutomirski cc: Lars Wendler , LKML , X86 ML , Borislav Betkov , Dave Hansen , Peter Zijlstra , Greg KH , Laura Abbott , Boris Ostrovsky , Juergen Gross Subject: Re: CONFIG_PAGE_TABLE_ISOLATION=y on x86_64 causes gcc to segfault when building x86_32 binaries In-Reply-To: Message-ID: References: <20180103123723.1dd26828@abudhabi.paradoxon.rec> <20180103143036.60e592eb@abudhabi.paradoxon.rec> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, 3 Jan 2018, Andy Lutomirski wrote: > On Wed, Jan 3, 2018 at 10:52 AM, Thomas Gleixner wrote: > > On Wed, 3 Jan 2018, Thomas Gleixner wrote: > > > >> On Wed, 3 Jan 2018, Lars Wendler wrote: > >> > Am Wed, 3 Jan 2018 13:05:38 +0100 (CET) > >> > schrieb Thomas Gleixner : > >> > > Also can you please try Linus v4.15-rc6 with PTI enabled so we can see > >> > > whether that's a backport issue or a general one? > >> > > >> > Same problem with 4.15-rc6. So I suppose that means it's a general > >> > issue. > >> > >> Just a shot in the dark as I just decoded another issue on a AMD CPU. Can > >> you please try the patch below? > > > > Ok. Found the real issue. This is a problem on AMD boxen. > > > > Fix below. > > > > Can Xen folks please have a look at that as well? > > > > Thanks, > > > > tglx > > > > 8<------------------- > > > > arch/x86/entry/entry_64_compat.S | 13 ++++++------- > > 1 file changed, 6 insertions(+), 7 deletions(-) > > > > --- a/arch/x86/entry/entry_64_compat.S > > +++ b/arch/x86/entry/entry_64_compat.S > > @@ -190,8 +190,13 @@ ENTRY(entry_SYSCALL_compat) > > /* Interrupts are off on entry. */ > > swapgs > > > > - /* Stash user ESP and switch to the kernel stack. */ > > + /* Stash user ESP */ > > movl %esp, %r8d > > + > > + /* Use %rsp as scratch reg. User ESP is stashed in r8 */ > > + SWITCH_TO_KERNEL_CR3 scratch_reg=%rsp > > + > > + /* Switch to the kernel stack */ > > movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp > > > > /* Construct struct pt_regs on stack */ > > @@ -220,12 +225,6 @@ GLOBAL(entry_SYSCALL_compat_after_hwfram > > pushq $0 /* pt_regs->r15 = 0 */ > > > > /* > > - * We just saved %rdi so it is safe to clobber. It is not > > - * preserved during the C calls inside TRACE_IRQS_OFF anyway. > > - */ > > - SWITCH_TO_KERNEL_CR3 scratch_reg=%rdi > > - > > - /* > > * User mode is traced as though IRQs are on, and SYSENTER > > * turned them off. > > */ > > What's the issue that this is fixing? > > movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp before switching CR3 is obviously broken ...