linux-kernel - Re: CONFIG_PAGE_TABLE_ISOLATION=y on x86_64 causes gcc to segfault when building x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5bdc44d-6c65-563f-a9cc-aee1d264d8f1@linux.intel.com>
Date:   Wed, 3 Jan 2018 07:42:08 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Lars Wendler <wendler.lars@....de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Borislav Betkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: CONFIG_PAGE_TABLE_ISOLATION=y on x86_64 causes gcc to segfault
 when building x86_32 binaries

On 01/03/2018 07:21 AM, Thomas Gleixner wrote:
> On Wed, 3 Jan 2018, Lars Wendler wrote:
>> Am Wed, 3 Jan 2018 13:05:38 +0100 (CET)
>> schrieb Thomas Gleixner <tglx@...utronix.de>:
>>> 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?

Hi Lars,

I see the double-faults in your dmesg.  Those are usually indicative of
a failed user->kernel CR3 switch on entering the kernel.

Could you run a copy of the x86 selftests?  From the kernel tree I
usually do:

	cd tools/testing/selftests/x86/
	make
	for i in *_64 *_32; do ./$i || break; done

See if any of those fail.

I wonder if we screwed up something in the SYSCALL code in
entry_64_compat.S.  It's probably been much more lightly tested than all
the other entry code.

I'll see if I can reproduce this.