linux-kernel - Re: [PATCH 42/43] x86/mm/kaiser: Allow KAISER to be enabled/disabled at runtime

lists.openwall.net		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 linux-hardening linux-cve-announce 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 16:21:03 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Ingo Molnar <mingo@...nel.org>,
        "linux-kernel@...r.kernel.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, Nov 25, 2017 at 2:48 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> 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.

One unfortunate thing is that, if we boot with kaiser off and don't
intend to ever switch it on at runtime, we could avoid the 8k pgd
allocations.  But if we want to be able to enable kaiser, we need the
8k mappings.  My inclination is to not try for runtime control until
some distro asks for it.

In general, I think that trying to runtime switch without stop_machine
is a bit nuts, and getting it to be reliable even with stop_machine is
gross.  Not to mention that stop_machine is currently incompatible
with writing to static branches, although that's fixable.

--Andy