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  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]
Date:   Sat, 25 Nov 2017 23:48:24 +0100 (CET)
From:   Thomas Gleixner <>
To:     Andy Lutomirski <>
cc:     Ingo Molnar <>,,
        Dave Hansen <>,
        "H . Peter Anvin" <>,
        Peter Zijlstra <>,
        Borislav Petkov <>,
        Linus Torvalds <>
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 <> 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.



Powered by blists - more mailing lists