linux-kernel - Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

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:   Fri, 5 May 2017 09:40:05 +0200
From:   Daniel Gruss <daniel.gruss@...k.tugraz.at>
To:     Christoph Hellwig <hch@...radead.org>
CC:     kernel list <linux-kernel@...r.kernel.org>,
        <kernel-hardening@...ts.openwall.com>,
        "clementine.maurice@...k.tugraz.at" 
        <clementine.maurice@...k.tugraz.at>,
        "moritz.lipp@...k.tugraz.at" <moritz.lipp@...k.tugraz.at>,
        Michael Schwarz <michael.schwarz@...k.tugraz.at>,
        Richard Fellner <richard.fellner@...dent.tugraz.at>,
        <kirill.shutemov@...ux.intel.com>,
        "Ingo Molnar" <mingo@...nel.org>,
        "anders.fogh@...ta-adan.de" <anders.fogh@...ta-adan.de>
Subject: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On 04.05.2017 17:47, Christoph Hellwig wrote:
> I'll try to read the paper.  In the meantime: how different is your
> approach from then one here?
>
> 	https://lwn.net/Articles/39283/
>
> and how different is the performance impact?

The approach sounds very similar, but we have fewer changes because we 
don't want to change memory allocation but only split the virtual memory 
- everything can stay where it is.

We found that the CR3 switch seems to be significantly improved in 
modern microarchitectures (we performed our performance tests on a 
Skylake i7-6700K). We think the TLB maybe uses the full CR3 base address 
as a tag, relaxing the necessity of flushing the entire TLB upon CR3 
updates a bit.
Direct runtime overhead is switching the CR3, but that's it.
Indirectly, we're potentially increasing the number of TLB entries that 
are required on one or the other level of the TLB. For TLB-intense tasks 
this might lead to more significant performance penalties.

I'm sure the overhead on older systems is larger than on recent systems.