linux-kernel - Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 5 Oct 2018 22:17:46 +0000
From:   Nadav Amit <namit@...are.com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap

at 3:10 PM, Andy Lutomirski <luto@...nel.org> wrote:

> On Fri, Oct 5, 2018 at 3:08 PM Nadav Amit <namit@...are.com> wrote:
>> at 10:02 AM, Andy Lutomirski <luto@...nel.org> wrote:
>> 
>>> On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit <namit@...are.com> wrote:
>>>> at 7:11 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>>> 
>>>>> On Oct 3, 2018, at 9:59 PM, Nadav Amit <namit@...are.com> wrote:
>>>>> 
>>>>>> This RFC proposes to return part of the entry-area back to the fixmap to
>>>>>> improve system-call performance. Currently, since the entry-area is
>>>>>> mapped far (more than 2GB) away from the kernel text, an indirect branch
>>>>>> is needed to jump from the trampoline into the kernel. Due to Spectre
>>>>>> v2, vulnerable CPUs need to use a retpoline, which introduces an
>>>>>> overhead of >20 cycles.
>>>>> 
>>>>> That retpoline is gone in -tip. Can you see how your code stacks up against -tip?  If it’s enough of a win to justify the added complexity, we can try it.
>>>>> 
>>>>> You can see some pros and cons in the changelog:
>>>>> 
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Ftip%2Fbf904d2762ee6fc1e4acfcb0772bbfb4a27ad8a6&amp;data=02%7C01%7Cnamit%40vmware.com%7C481a83f5323242399efd08d62b0f69ba%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636743742543114742&amp;sdata=uI5X3PITzEVeXHyafSGNV6oVNklpHbmhhRbtyoIurkk%3D&amp;reserved=0
>>>> 
>>>> Err.. That’s what I get for not following lkml. Very nice discussion.
>>>> Based on it, I may be able to do an additional micro-optimizations or
>>>> two. Let me give it a try.
>>> 
>>> I think you should at least try to benchmark your code against mine,
>>> since you more or less implemented the alternative I suggested. :)
>> 
>> That’s what I meant. So I made a couple of tweaksin my implementation to
>> make as performant as possible. Eventually, there is a 2ns benefit for the
>> trampoline over the unified entry-path on average on my Haswell VM (254ns vs
>> 256ns), yet there is some variance (1.2 & 1.5ns stdev correspondingly).
>> 
>> I don’t know whether such a difference should make one option to be preferred
>> over the other. I think it boils down to whether:
>> 
>> 1. KASLR is needed.
> 
> Why?  KASLR is basically worthless on any existing CPU against
> attackers who can run local code.
> 
>> 2. Can you specialize the code-paths of trampoline/non-trampoline to gain
>> better performance. For example, by removing the ALTERNATIVE from
>> SWITCH_TO_KERNEL_CR3 and not reload CR3 on the non-trampoline path, you can
>> avoid an unconditional jmp on machines which are not vulnerable to Meltdown.
>> 
>> So I can guess what you’d prefer. Let’s see if I’m right.
> 
> 2 ns isn't bad, at least on a non-PTI system.  Which, I suppose, means
> that you should benchmark on AMD :)
> 
> If the code is reasonably clean, I could get on board.

Fair enough. I’ll clean it and resend.

Thanks,
Nadav