[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1711252326460.2316@nanos>
Date: Sat, 25 Nov 2017 23:48:24 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...capital.net>
cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled
at runtime
On Sat, 25 Nov 2017, Andy Lutomirski wrote:
> > On Nov 25, 2017, at 1:05 PM, Thomas Gleixner <tglx@...utronix.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
Powered by blists - more mailing lists