Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
On Thu, May 29, 2014 at 12:43 PM, H. Peter Anvin wrote: > On 05/29/2014 12:32 PM, Andy Lutomirski wrote: >> On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker >> wrote: >>> On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski >>> wrote: Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829 Gitweb: http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829 Author: Andy Lutomirski AuthorDate: Mon, 5 May 2014 12:19:34 -0700 Committer: H. Peter Anvin CommitDate: Mon, 5 May 2014 13:18:51 -0700 x86, vdso: Reimplement vdso.so preparation in build-time C >>> >>> Just a heads up in case it hasn't been mentioned already; >>> the x86 builds in linux-next which IIRC are done as cross >>> compile on a powerpc box are failing as follows: >>> >>> VDSO2C arch/x86/vdso/vdso-image-64.c >>> /bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c >>> arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c >>> make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139 >>> >>> http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/ >>> >> >> Egads. This wouldn't be a big-endian host by any chance? >> > > He said PowerPC; most but not all PowerPC systems are bigendian. Seems > like a fair assumption to make. > I suppose I shouldn't have assumed that code in arch/x86 would always run on little-endian machines. I'll fix it. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
On 05/29/2014 12:32 PM, Andy Lutomirski wrote: > On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker > wrote: >> On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski >> wrote: >>> Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829 >>> Gitweb: >>> http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829 >>> Author: Andy Lutomirski >>> AuthorDate: Mon, 5 May 2014 12:19:34 -0700 >>> Committer: H. Peter Anvin >>> CommitDate: Mon, 5 May 2014 13:18:51 -0700 >>> >>> x86, vdso: Reimplement vdso.so preparation in build-time C >> >> Just a heads up in case it hasn't been mentioned already; >> the x86 builds in linux-next which IIRC are done as cross >> compile on a powerpc box are failing as follows: >> >> VDSO2C arch/x86/vdso/vdso-image-64.c >> /bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c >> arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c >> make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139 >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/ >> > > Egads. This wouldn't be a big-endian host by any chance? > He said PowerPC; most but not all PowerPC systems are bigendian. Seems like a fair assumption to make. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
On Thu, May 29, 2014 at 3:32 PM, Andy Lutomirski wrote: > On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker > wrote: >> On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski >> wrote: >>> Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829 >>> Gitweb: >>> http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829 >>> Author: Andy Lutomirski >>> AuthorDate: Mon, 5 May 2014 12:19:34 -0700 >>> Committer: H. Peter Anvin >>> CommitDate: Mon, 5 May 2014 13:18:51 -0700 >>> >>> x86, vdso: Reimplement vdso.so preparation in build-time C >> >> Just a heads up in case it hasn't been mentioned already; >> the x86 builds in linux-next which IIRC are done as cross >> compile on a powerpc box are failing as follows: >> >> VDSO2C arch/x86/vdso/vdso-image-64.c >> /bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c >> arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c >> make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139 >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/ >> > > Egads. This wouldn't be a big-endian host by any chance? Likely if it's really a cross compile on a powerpc machine. Virtually all existing powerpc machines are big-endian. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker wrote: > On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski > wrote: >> Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829 >> Gitweb: >> http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829 >> Author: Andy Lutomirski >> AuthorDate: Mon, 5 May 2014 12:19:34 -0700 >> Committer: H. Peter Anvin >> CommitDate: Mon, 5 May 2014 13:18:51 -0700 >> >> x86, vdso: Reimplement vdso.so preparation in build-time C > > Just a heads up in case it hasn't been mentioned already; > the x86 builds in linux-next which IIRC are done as cross > compile on a powerpc box are failing as follows: > > VDSO2C arch/x86/vdso/vdso-image-64.c > /bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c > arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c > make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139 > > http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/ > Egads. This wouldn't be a big-endian host by any chance? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski wrote: > Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829 > Gitweb: http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829 > Author: Andy Lutomirski > AuthorDate: Mon, 5 May 2014 12:19:34 -0700 > Committer: H. Peter Anvin > CommitDate: Mon, 5 May 2014 13:18:51 -0700 > > x86, vdso: Reimplement vdso.so preparation in build-time C Just a heads up in case it hasn't been mentioned already; the x86 builds in linux-next which IIRC are done as cross compile on a powerpc box are failing as follows: VDSO2C arch/x86/vdso/vdso-image-64.c /bin/sh: line 1: 15995 Segmentation fault arch/x86/vdso/vdso2c arch/x86/vdso/vdso64.so.dbg arch/x86/vdso/vdso-image-64.c make[3]: *** [arch/x86/vdso/vdso-image-64.c] Error 139 http://kisskb.ellerman.id.au/kisskb/buildresult/11265454/ Paul. -- > > Currently, vdso.so files are prepared and analyzed by a combination > of objcopy, nm, some linker script tricks, and some simple ELF > parsers in the kernel. Replace all of that with plain C code that > runs at build time. > > All five vdso images now generate .c files that are compiled and > linked in to the kernel image. > > This should cause only one userspace-visible change: the loaded vDSO > images are stripped more heavily than they used to be. Everything > outside the loadable segment is dropped. In particular, this causes > the section table and section name strings to be missing. This > should be fine: real dynamic loaders don't load or inspect these > tables anyway. The result is roughly equivalent to eu-strip's > --strip-sections option. > > The purpose of this change is to enable the vvar and hpet mappings > to be moved to the page following the vDSO load segment. Currently, > it is possible for the section table to extend into the page after > the load segment, so, if we map it, it risks overlapping the vvar or > hpet page. This happens whenever the load segment is just under a > multiple of PAGE_SIZE. > > The only real subtlety here is that the old code had a C file with > inline assembler that did 'call VDSO32_vsyscall' and a linker script > that defined 'VDSO32_vsyscall = __kernel_vsyscall'. This most > likely worked by accident: the linker script entry defines a symbol > associated with an address as opposed to an alias for the real > dynamic symbol __kernel_vsyscall. That caused ld to relocate the > reference at link time instead of leaving an interposable dynamic > relocation. Since the VDSO32_vsyscall hack is no longer needed, I > now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it > work. vdso2c will generate an error and abort the build if the > resulting image contains any dynamic relocations, so we won't > silently generate bad vdso images. > > (Dynamic relocations are a problem because nothing will even attempt > to relocate the vdso.) > > Signed-off-by: Andy Lutomirski > Link: > http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.l...@amacapital.net > Signed-off-by: H. Peter Anvin > --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/vdso] x86, vdso: Reimplement vdso.so preparation in build-time C
Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829
Gitweb: http://git.kernel.org/tip/6f121e548f83674ab4920a4e60afb58d4f61b829
Author: Andy Lutomirski
AuthorDate: Mon, 5 May 2014 12:19:34 -0700
Committer: H. Peter Anvin
CommitDate: Mon, 5 May 2014 13:18:51 -0700
x86, vdso: Reimplement vdso.so preparation in build-time C
Currently, vdso.so files are prepared and analyzed by a combination
of objcopy, nm, some linker script tricks, and some simple ELF
parsers in the kernel. Replace all of that with plain C code that
runs at build time.
All five vdso images now generate .c files that are compiled and
linked in to the kernel image.
This should cause only one userspace-visible change: the loaded vDSO
images are stripped more heavily than they used to be. Everything
outside the loadable segment is dropped. In particular, this causes
the section table and section name strings to be missing. This
should be fine: real dynamic loaders don't load or inspect these
tables anyway. The result is roughly equivalent to eu-strip's
--strip-sections option.
The purpose of this change is to enable the vvar and hpet mappings
to be moved to the page following the vDSO load segment. Currently,
it is possible for the section table to extend into the page after
the load segment, so, if we map it, it risks overlapping the vvar or
hpet page. This happens whenever the load segment is just under a
multiple of PAGE_SIZE.
The only real subtlety here is that the old code had a C file with
inline assembler that did 'call VDSO32_vsyscall' and a linker script
that defined 'VDSO32_vsyscall = __kernel_vsyscall'. This most
likely worked by accident: the linker script entry defines a symbol
associated with an address as opposed to an alias for the real
dynamic symbol __kernel_vsyscall. That caused ld to relocate the
reference at link time instead of leaving an interposable dynamic
relocation. Since the VDSO32_vsyscall hack is no longer needed, I
now use 'call __kernel_vsyscall', and I added -Bsymbolic to make it
work. vdso2c will generate an error and abort the build if the
resulting image contains any dynamic relocations, so we won't
silently generate bad vdso images.
(Dynamic relocations are a problem because nothing will even attempt
to relocate the vdso.)
Signed-off-by: Andy Lutomirski
Link:
http://lkml.kernel.org/r/2c4fcf45524162a34d87fdda1eb046b2a5cecee7.1399317206.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin
---
arch/x86/ia32/ia32_signal.c | 8 +--
arch/x86/include/asm/elf.h| 7 +-
arch/x86/include/asm/mmu.h| 2 +-
arch/x86/include/asm/vdso.h | 70 +++
arch/x86/kernel/signal.c | 6 +-
arch/x86/mm/init_64.c | 3 +-
arch/x86/vdso/.gitignore | 5 +-
arch/x86/vdso/Makefile| 90 +---
arch/x86/vdso/vclock_gettime.c| 4 +-
arch/x86/vdso/vdso.S | 3 -
arch/x86/vdso/vdso2c.c| 142 ++
arch/x86/vdso/vdso2c.h| 137
arch/x86/vdso/vdso32-setup.c | 50 ++
arch/x86/vdso/vdso32.S| 9 ---
arch/x86/vdso/vdso32/vdso32.lds.S | 10 ---
arch/x86/vdso/vdsox32.S | 3 -
arch/x86/vdso/vma.c | 100 +--
arch/x86/xen/setup.c | 11 ++-
18 files changed, 400 insertions(+), 260 deletions(-)
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 2206757..f9e181a 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -383,8 +383,8 @@ int ia32_setup_frame(int sig, struct ksignal *ksig,
} else {
/* Return stub is in 32bit vsyscall page */
if (current->mm->context.vdso)
- restorer = VDSO32_SYMBOL(current->mm->context.vdso,
-sigreturn);
+ restorer = current->mm->context.vdso +
+ selected_vdso32->sym___kernel_sigreturn;
else
restorer = &frame->retcode;
}
@@ -462,8 +462,8 @@ int ia32_setup_rt_frame(int sig, struct ksignal *ksig,
if (ksig->ka.sa.sa_flags & SA_RESTORER)
restorer = ksig->ka.sa.sa_restorer;
else
- restorer = VDSO32_SYMBOL(current->mm->context.vdso,
-rt_sigreturn);
+ restorer = current->mm->context.vdso +
+ selected_vdso32->sym___kernel_rt_sigreturn;
put_user_ex(ptr_to_compat(restorer), &frame->pretcode);
/*
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e96df2c..65b21bc 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -299,7 +299,7 @@ do {
