Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753591AbeAMUCD (ORCPT + 1 other); Sat, 13 Jan 2018 15:02:03 -0500 Received: from mail.kernel.org ([198.145.29.99]:42982 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750951AbeAMUCB (ORCPT ); Sat, 13 Jan 2018 15:02:01 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 90C0D2177E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBovT8XGZQq+n1Pc33XotLBplx0ZE0Y4iiCTsgDl8RL2vBG/93CDPxjndQt0qOfXGzU2MZ70/dc7PVRS26JvCc8E= MIME-Version: 1.0 In-Reply-To: <20180113063320.GC16821@1wt.eu> References: <9eb15489-da09-7a4c-0700-7b6eb99e6f7b@redhat.com> <20180113063320.GC16821@1wt.eu> From: Andy Lutomirski Date: Sat, 13 Jan 2018 12:01:39 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Yet another KPTI regression with 4.14.x series in a VM To: Willy Tarreau Cc: Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , Laura Abbott , X86 ML , Linux Kernel Mailing List , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, Jan 12, 2018 at 10:33 PM, Willy Tarreau wrote: > On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote: >> In fact, it looks like this code is totally bogus and has never been >> correct at all. Even in: >> >> commit 4b1d5ae3b103eda43f9d0f85c355bb6995b03a30 >> Author: Peter Zijlstra >> Date: Mon Dec 4 15:07:59 2017 +0100 >> >> x86/mm: Use/Fix PCID to optimize user/kernel switches >> >> We have: >> >> .macro SWITCH_TO_USER_CR3_NOSTACK scratch_reg:req scratch_reg2:req >> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI >> mov %cr3, \scratch_reg >> >> ALTERNATIVE "jmp .Lwrcr3_\@", "", X86_FEATURE_PCID >> >> ... >> >> .Lwrcr3_\@: >> /* Flip the PGD and ASID to the user version */ >> orq $(PTI_SWITCH_MASK), \scratch_reg >> mov \scratch_reg, %cr3 >> .Lend_\@: >> >> That's bogus. PTI_SWITCH_MASK is 0x1800, which has PCID = 0x800. >> >> This should probably use an alternative to select between 0x1000 and >> 0x800 depending on X86_FEATURE_PCID or just use an entirely different >> label for the !PCID case. >> >> FWIW, this bit in SAVE_AND_SWITCH_TO_KERNEL_CR3 >> >> testq $(PTI_SWITCH_MASK), \scratch_reg >> jz .Ldone_\@ >> >> is a bit silly, too. It's *correct* (I think), but shouldn't that >> just be bt $(PTI_SWITCH_PGTABLES_BIT), \scratch_reg, with the obvious >> caveat that the headers don't actually define PTI_SWITCH_PGTABLES_BIT? > > I wondered the same initially when reading this but thought there was > surely a good reason that I could not understand due to my lack of > knowledge and stopped wondering. BTW your PTI_SWITCH_PGTABLES_BIT would > in fact be PAGE_SHIFT :-) Trying to inventory this stuff scattered all over the place: #define PTI_PGTABLE_SWITCH_BIT PAGE_SHIFT #define PTI_SWITCH_PGTABLES_MASK (1<