linux-kernel - Re: [PATCH v16 0/10] Add 32 bit VDSO time function support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1392474801.1585.8.camel@wall-e.seibold.net>
Date:	Sat, 15 Feb 2014 15:33:21 +0100
From:	Stefani Seibold <stefani@...bold.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, tglx@...utronix.de, mingo@...hat.com,
	ak@...ux.intel.com, aarcange@...hat.com, john.stultz@...aro.org,
	luto@...capital.net, xemul@...allels.com, gorcunov@...nvz.org,
	andriy.shevchenko@...ux.intel.com, Martin.Runge@...de-schwarz.com,
	Andreas.Brief@...de-schwarz.com
Subject: Re: [PATCH v16 0/10] Add 32 bit VDSO time function support


Am Freitag, den 14.02.2014, 14:32 -0800 schrieb H. Peter Anvin:
> I still get build errors.
> 

Oops, i did it again...

> i386 allyesconfig, i386 allmodconfig as well as a more basic i386
> configuration:
> 
> arch/x86/vdso/vdso32-int80.so.dbg: undefined symbols found
> make[4]: *** [arch/x86/vdso/vdso32-int80.so.dbg] Error 1
> 

The problem is the call of vget_cycles() in function vread_tsc().

vget_cycles() will access  cpu_has_tsc which is a macro which access
boot_cpu_data, which is not available in a VDSO.

But i think it is save to replace the call by __native_read_tsc() and
skip the test of cpu_has_tsc, because vread_tsc() will be only invoked
when gtod->vclock_mode == VCLOCK_TSC. Since the kernel will set this
when the TSC is the current clock, the CPU must have a TSC.

There was also a issue with arch/x86/tools/relocs.c, the __vvar_page
must be outside the #if ELF_BITS == 64

So i tested it now with

make distclean
make ARCH=i386 allyesconfig

And it compiles a kernel without an error.

> x86-64 allyesconfig and x86-64 allmodconfig:
> 
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:128:4: warning:
> symbol 'hpet_page' was not declared
> . Should it be static?
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
> warning: incorrect type in argument 1 (diff
> erent address spaces)
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
>    expected void const volatile [noderef] <
> asn:2>*addr
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:134:33:
>    got unsigned char [toplevel] *
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:294:13:
> warning: symbol '__vdso_clock_gettime' was
> not declared. Should it be static?
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:322:13:
> warning: symbol '__vdso_gettimeofday' was n
> ot declared. Should it be static?
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/../vclock_gettime.c:343:16:
> warning: symbol '__vdso_time' was not decla
> red. Should it be static?
>   CC      arch/x86/vdso/vdso32/vclock_gettime.o
> /home/hpa/kernel/distwork/arch/x86/vdso/vdso32/vclock_gettime.c:1:0:
> sorry, unimplemented: -mfentry isn’t supported fo
> r 32-bit in combination with -fpic
>  #define BUILD_VDSO32
>  ^
> make[4]: *** [arch/x86/vdso/vdso32/vclock_gettime.o] Error 1
> make[3]: *** [arch/x86/vdso] Error 2
> make[3]: *** Waiting for unfinished jobs....
> 
> This is after I removed the incorrect "generated/" filename prefix in
> patch 9.
> 

make distclean
make allyesconfig

Compiles without an error.

Why is the

#include <generated/asm/unistd_32_ia32.h>

incorrect?

The bit kernel syscall function numbers are needed in case build a 32
bit VDSO for a 64 bit kernel.

A quick "find . -name \*.c | xargs grep 'generated/'" in the kernel
sources showed up 38 includes of a generated header.

If it is incorrect to include a generated header why therefore are
generated? Only to waste disc space?

- Stefani

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/