Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932618AbcCUTcM (ORCPT ); Mon, 21 Mar 2016 15:32:12 -0400 Received: from mail-ob0-f196.google.com ([209.85.214.196]:35972 "EHLO mail-ob0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756203AbcCUTcK (ORCPT ); Mon, 21 Mar 2016 15:32:10 -0400 MIME-Version: 1.0 In-Reply-To: <20160321185429.GY5083@two.firstfloor.org> References: <1458576969-13309-1-git-send-email-andi@firstfloor.org> <1458576969-13309-5-git-send-email-andi@firstfloor.org> <20160321185429.GY5083@two.firstfloor.org> Date: Mon, 21 Mar 2016 15:32:09 -0400 Message-ID: Subject: Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 From: Brian Gerst To: Andi Kleen Cc: "the arch/x86 maintainers" , Andy Lutomirski , Linux Kernel Mailing List , Andi Kleen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2072 Lines: 47 On Mon, Mar 21, 2016 at 2:54 PM, Andi Kleen wrote: > On Mon, Mar 21, 2016 at 02:49:44PM -0400, Brian Gerst wrote: >> On Mon, Mar 21, 2016 at 12:16 PM, Andi Kleen wrote: >> > From: Andi Kleen >> > >> > 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 It would be less complicated actually, as normal userspace would just continue to call arch_prctl() as it does today. Glibc would implement arch_prctl() just like it does with gettimeofday() -- with an ifunc selector [1] that calls the VDSO function if it is available, or the syscall if not. No custom assembly needed. [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86/gettimeofday.c;h=36f7c26ffb0e818709d032c605fec8c4bd22a14e;hb=HEAD -- Brian Gerst