From: Andi Kleen <andi@firstfloor.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>,
the arch/x86 maintainers <x86@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2
Date: Mon, 21 Mar 2016 19:54:29 +0100 [thread overview]
Message-ID: <20160321185429.GY5083@two.firstfloor.org> (raw)
In-Reply-To: <CAMzpN2jBESkrGgZnVD4N-gHC_1-oRH+eXCCEkDpSGjHMzMTBzA@mail.gmail.com>
On Mon, Mar 21, 2016 at 02:49:44PM -0400, Brian Gerst wrote:
> On Mon, Mar 21, 2016 at 12:16 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > The kernel needs to explicitely enable RD/WRFSBASE to handle context
> > switch correctly. So the application needs to know if it can safely use
> > these instruction. Just looking at the CPUID bit is not enough because it
> > may be running in a kernel that does not enable the instructions.
> >
> > One way for the application would be to just try and catch the SIGILL.
> > But that is difficult to do in libraries which may not want
> > to overwrite the signal handlers of the main application.
> >
> > So we need to provide a way for the application to discover the kernel
> > capability.
> >
> > I used AT_HWCAP2 in the ELF aux vector which is already used by
> > PPC for similar things. We define a new Linux defined bitmap
> > returned in AT_HWCAP. Currently it has only one bit set,
> > for kernel is FSGSBASE capable.
> >
> > The application can then access it manually or using
> > the getauxval() function in newer glibc.
>
> How about adding a VDSO function instead? The VDSO can use
> alternatives, so it can use the new instructions if supported, or else
> use the old syscall.
What would be the point of that?
It would be a lot more complicated, and I don't see any advantages
over the aux vector. vdso also requires custom assembler
stubs in the C library.
-Andi
next prev parent reply other threads:[~2016-03-21 19:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 16:16 Updated version of RD/WR FS/GS BASE patchkit Andi Kleen
2016-03-21 16:16 ` [PATCH 1/9] x86: Add intrinsics/macros for new rd/wr fs/gs base instructions Andi Kleen
2016-03-21 18:14 ` Andy Lutomirski
2016-03-21 16:16 ` [PATCH 2/9] x86: Add support for rd/wr fs/gs base Andi Kleen
2016-03-21 18:13 ` Andy Lutomirski
2016-03-21 19:05 ` Andi Kleen
2016-03-21 19:22 ` Andy Lutomirski
2016-03-21 22:05 ` Andi Kleen
2016-03-21 22:08 ` Andy Lutomirski
2016-03-21 22:15 ` Andi Kleen
2016-03-22 8:36 ` Thomas Gleixner
2016-03-22 14:40 ` Brian Gerst
2016-04-15 0:06 ` Andy Lutomirski
2016-03-21 16:16 ` [PATCH 3/9] x86: Make old K8 swapgs workaround conditional Andi Kleen
2016-03-21 16:16 ` [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Andi Kleen
2016-03-21 18:49 ` Brian Gerst
2016-03-21 18:54 ` Andi Kleen [this message]
2016-03-21 19:32 ` Brian Gerst
2016-03-21 19:43 ` Andi Kleen
2016-03-21 22:10 ` Andy Lutomirski
2016-03-21 16:16 ` [PATCH 5/9] x86: Add documentation for rd/wr fs/gs base Andi Kleen
2016-03-23 19:14 ` Valdis.Kletnieks
2016-03-21 16:16 ` [PATCH 6/9] x86: Use rd/wr fs/gs base in arch_prctl Andi Kleen
2016-03-21 18:17 ` Andy Lutomirski
2016-03-21 16:16 ` [PATCH 7/9] x86: Add self test code for fsgsbase Andi Kleen
2016-03-21 16:16 ` [PATCH 8/9] x86: Support arbitrary fs/gs base in getregs Andi Kleen
2016-03-21 16:16 ` [PATCH 9/9] x86: Save FS/GS base in core dump Andi Kleen
2016-03-21 18:39 ` Updated version of RD/WR FS/GS BASE patchkit Andy Lutomirski
2016-03-21 19:03 ` Andi Kleen
2016-03-21 19:23 ` Andy Lutomirski
2016-03-21 19:40 ` Andi Kleen
2016-03-21 22:05 ` Andy Lutomirski
2016-03-21 22:11 ` Andi Kleen
2016-03-21 22:27 ` Andy Lutomirski
2016-03-21 22:41 ` Andi Kleen
2016-03-21 22:47 ` Andy Lutomirski
2016-03-21 22:52 ` Andi Kleen
2016-03-21 22:57 ` Andy Lutomirski
2016-03-21 23:02 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160321185429.GY5083@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=ak@linux.intel.com \
--cc=brgerst@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.