Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181004045948.129142-1-namit@vmware.com> <72B0B378-9515-47C4-8937-9F1E823DD236@amacapital.net>
 <CE9C4B9C-3B11-45D0-812A-F074D687084D@vmware.com> <CALCETrVkE9eV0b2-wfq4Y9iK+YVJ4JBL7_rk_A8-7EhtuBbncA@mail.gmail.com>
 <2A4D16C3-CBE2-490F-8C7A-F5FE437ACC34@vmware.com>
In-Reply-To: <2A4D16C3-CBE2-490F-8C7A-F5FE437ACC34@vmware.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Fri, 5 Oct 2018 15:10:38 -0700
Message-ID: <CALCETrUnN-sQErp+q=RZU-9Gwg6GaDaoQzSjNv2=hcLej3NfsQ@mail.gmail.com>
Subject: Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap
To:     Nadav Amit <namit@vmware.com>
Cc:     Andrew Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        "Woodhouse, David" <dwmw@amazon.co.uk>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Oct 5, 2018 at 3:08 PM Nadav Amit <namit@vmware.com> wrote:
>
> at 10:02 AM, Andy Lutomirski <luto@kernel.org> wrote:
>
> > On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit <namit@vmware.com> wrote:
> >> at 7:11 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> >>
> >>> On Oct 3, 2018, at 9:59 PM, Nadav Amit <namit@vmware.com> wrote:
> >>>
> >>>> This RFC proposes to return part of the entry-area back to the fixma=
p to
> >>>> improve system-call performance. Currently, since the entry-area is
> >>>> mapped far (more than 2GB) away from the kernel text, an indirect br=
anch
> >>>> is needed to jump from the trampoline into the kernel. Due to Spectr=
e
> >>>> 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 a=
gainst -tip?  If it=E2=80=99s enough of a win to justify the added complexi=
ty, we can try it.
> >>>
> >>> You can see some pros and cons in the changelog:
> >>>
> >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi=
t.kernel.org%2Ftip%2Fbf904d2762ee6fc1e4acfcb0772bbfb4a27ad8a6&amp;data=3D02=
%7C01%7Cnamit%40vmware.com%7C9996b2dd6f1745dce10b08d62a1b3f3e%7Cb39138ca3ce=
e4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636742693864878787&amp;sdata=3DNW0R%2Fv5Oah=
ZlTbbNgnFk20sF4Wt1W0MDjtv9g1k%2BWdg%3D&amp;reserved=3D0
> >>
> >> Err.. That=E2=80=99s what I get for not following lkml. Very nice disc=
ussion.
> >> 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=E2=80=99s what I meant. So I made a couple of tweaksin my implementa=
tion to
> make as performant as possible. Eventually, there is a 2ns benefit for th=
e
> 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=E2=80=99t 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 c=
an
> avoid an unconditional jmp on machines which are not vulnerable to Meltdo=
wn.
>
> So I can guess what you=E2=80=99d prefer. Let=E2=80=99s see if I=E2=80=99=
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.