Subject: Re: 4.14.9 with CONFIG_MCORE2 fails to boot
To: Alexander Tsoy <alexander@tsoy.me>, Greg KH <greg@kroah.com>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
References: <1514453602.6251.8.camel@tsoy.me>
 <20171229091741.GC18441@kroah.com> <1514557888.28262.1.camel@tsoy.me>
 <1514558513.28262.3.camel@tsoy.me>
 <1b4569ee-8c06-4480-447b-2af8f6804053@intel.com>
 <1514573194.28262.9.camel@tsoy.me>
Cc: Borislav Petkov <bp@suse.de>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Borislav Petkov <bp@alien8.de>, Borislav Petkov <bpetkov@suse.de>,
        Brian Gerst <brgerst@gmail.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Laight <David.Laight@aculab.com>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Eduardo Valentin <eduval@amazon.com>,
        Greg KH <gregkh@linuxfoundation.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>, Juergen Gross <jgross@suse.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>, Rik van Riel <riel@redhat.com>,
        Will Deacon <will.deacon@arm.com>, aliguori@amazon.com,
        daniel.gruss@iaik.tugraz.at, hughd@google.com, keescook@google.com,
        Kernel Mailing List <linux-kernel@vger.kernel.org>,
        stable <stable@vger.kernel.org>
From: Dave Hansen <dave.hansen@intel.com>
Message-ID: <c1cb0fb3-ed36-771d-447d-e9f12662a240@intel.com>
Date: Fri, 29 Dec 2017 17:04:56 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1514573194.28262.9.camel@tsoy.me>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1241
Lines: 28

On 12/29/2017 10:46 AM, Alexander Tsoy wrote:
> В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет:
>> Does anyone have the results of build that they can share?  (vmlinux,
>> vmlinuz/bzImage, System.map, .config).  That, plus a corresponding
>> serial log with an oops would be helpful.
> 
> Here you are:
> https://www.dropbox.com/s/yesupqgig3uxf73/linux-4.15-rc5%2B.tar.xz?dl=0

Alexander, thanks a bunch for the quick turnaround on this.  It is much
appreciated!

With your binary, I can reproduce this in a KVM guest.  Seems we manage
to get to paranoid_entry with a kernel GS value, but the user page
tables in place.  We don't smash the #DF stack because we reset the
stack at each new #DF.  I think the loop that we get stuck in goes
something like this:

1. Hardware does #DF, calls double_fault
2. call paranoid_entry
3. check MSR for GSBASE, see it has kernel value, skip SWAPGS and
   switch to kernel page tables
4. touch stack, try to #PF, but can't touch stack, so #DF and goto 1

The real question is where we double-faulted from in the first place
with a kernel GSBASE and user CR3.  I think I just need to disable KASLR
and do a little work in gdb to look at the stack on the first
double-fault, but we'll see.