at 3:10 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Fri, Oct 5, 2018 at 3:08 PM Nadav Amit <na...@vmware.com> wrote: >> at 10:02 AM, Andy Lutomirski <l...@kernel.org> wrote: >> >>> On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit <na...@vmware.com> wrote: >>>> at 7:11 AM, Andy Lutomirski <l...@amacapital.net> wrote: >>>> >>>>> On Oct 3, 2018, at 9:59 PM, Nadav Amit <na...@vmware.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&data=02%7C01%7Cnamit%40vmware.com%7C481a83f5323242399efd08d62b0f69ba%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636743742543114742&sdata=uI5X3PITzEVeXHyafSGNV6oVNklpHbmhhRbtyoIurkk%3D&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
