From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751899AbdKYWs3 (ORCPT <rfc822;w@1wt.eu>);
        Sat, 25 Nov 2017 17:48:29 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:50680 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751748AbdKYWs2 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 25 Nov 2017 17:48:28 -0500
Date: Sat, 25 Nov 2017 23:48:24 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Lutomirski <luto@amacapital.net>
cc: Ingo Molnar <mingo@kernel.org>, linux-kernel@vger.kernel.org,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled
 at runtime
In-Reply-To: <A04ECEDE-7EDA-41AE-8ED5-DFD473827C2A@amacapital.net>
Message-ID: <alpine.DEB.2.20.1711252326460.2316@nanos>
References: <20171124172411.19476-1-mingo@kernel.org> <20171124172411.19476-43-mingo@kernel.org> <alpine.DEB.2.20.1711252002550.2316@nanos> <47186975-1DCB-4767-8C4C-0816931E3595@amacapital.net> <alpine.DEB.2.20.1711252100010.2316@nanos>
 <A04ECEDE-7EDA-41AE-8ED5-DFD473827C2A@amacapital.net>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 25 Nov 2017, Andy Lutomirski wrote:
> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Sat, 25 Nov 2017, Andy Lutomirski wrote:
> >> Keep in mind that, for a static_branch, actually setting the thing needs
> >> to be deferred, but that's straightforward.
> > 
> > That's not an issue during boot. That would be an issue for a run time
> > switch.
> 
> What I mean is: if you modify a static_branch too early, it blows up terribly.

I'm aware of that. We can't switch it in the early boot stage. But that
does not matter as we can switch way before we reach user space.

The early kaiser mappings are fine whether we use them later or not. At the
point in boot where we actually make the decision, there is nothing more
than the extra 4k shadow which got initialized.

If we ever want to do runtime switching, then the full shadow mapping needs
to be maintained even while kaiser is disabled, just the NX poisoning of
the user space mappings is what makes the difference.

Thanks,

	tglx