linux-kernel - Re: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include < linux/spinlock

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]

Date:	Mon, 17 Feb 2014 01:50:03 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Stefani Seibold <stefani@...bold.net>
CC:	mingo@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	hpa@...ux.intel.com, linux-tip-commits@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [tip:x86/vdso] x86, vdso: Instead of dummy functions, include
 < linux/spinlock_up.h>

On 02/17/2014 01:46 AM, Stefani Seibold wrote:
> Am Montag, den 17.02.2014, 01:27 -0800 schrieb H. Peter Anvin:
>> On 02/16/2014 11:42 PM, Stefani Seibold wrote:
>>> I think for the first time it will be okay to kick out the
>>> _ASM_X86_SPINLOCK_H hack and accept the C=1 warnings.
>>>
>>> At next step it is necessary to make the whole BUILD_VDSO32 path in
>>> vclock_gettime.c independent from the kernel headers, only uapi/ should
>>> be included.
>>>
>>> The use of cycle_t must be replaced with u64.
>>>
>>> We need a own copy of __native_read_tsc(), __iter_div_u64_rem, smp_rmb()
>>> and cpu_relax().
>>
>> All of which are quite trivial.
>>
>>> For the non BUILD_VDSO32 path we must only move the #includes inside
>>> this #ifndef BUILD_VDSO32
>>
>> Sorry, didn't quite follow that.
>>
>
> The solution is quite simple: In case of a 32 bit VDSO for a 64 bit
> kernel fake a 32 bit kernel configuration. Than everything is fine and
> all kernel headers will compile without warnings or errors, also make
> C=1 will give no complains.
>
> The arch/x86/vdso/vdso32/vclock_gettime.c will now look like:
>
> #define BUILD_VDSO32
>
> #ifdef CONFIG_X86_64
>
> /*
>   * in case of a 32 bit VDSO for a 64 bit kernel fake a 32 bit kernel
>   * configuration
>   */
> #undef CONFIG_64BIT
> #undef CONFIG_X86_64
> #undef CONFIG_ILLEGAL_POINTER_VALUE
>
> #define CONFIG_X86_32 1
> #define CONFIG_PAGE_OFFSET 0
> #define CONFIG_ILLEGAL_POINTER_VALUE 0
>
> #define BUILD_VDSO32_64
>
> #endif
>
> #include "../vclock_gettime.c"
>
> and the following modifications for arch/x86/include/asm/vgtod.h:
>
> #ifdef BUILD_VDSO32_64
> typedef u64 gtod_long_t;
> #else
> typedef unsigned long gtod_long_t;
> #endif
>
> I tested it and i see no side effects. What do you think?
>

Clever.  It is still a hack of course, and it would be better to getting 
to the point where we don't include random kernel headers but only uapi 
headers plus special headers sanitized specifically for the vdso, but 
the above looks like a good intermediate hack.

	-hpa


--
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/