linux-kernel - Re: [PATCH 3/4] Add 32 bit VDSO time support for 32 bit kernel

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:	Sat, 01 Feb 2014 16:56:56 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Stefani Seibold <stefani@...bold.net>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	John Stultz <john.stultz@...aro.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	andriy.shevchenko@...ux.intel.com, Martin.Runge@...de-schwarz.com,
	Andreas.Brief@...de-schwarz.com,
	Roland McGrath <roland@...k.frob.com>
Subject: Re: [PATCH 3/4] Add 32 bit VDSO time support for 32 bit kernel

On 02/01/2014 04:41 PM, H. Peter Anvin wrote:
>>
>> Right.  But there's some obscure ABI reason for CONFIG_COMPAT_VDSO,
>> and if this breaks it, then it's no good.  From extremely vague
>> memory, there's some version of SuSE that breaks if the 32-bit vdso
>> moves.  I have no idea what the bug is, but moving a "compat" address
>> seems suspect.
>>

Sure enough:

> config COMPAT_VDSO
>         def_bool y
>         prompt "Compat VDSO support"
>         depends on X86_32 || IA32_EMULATION
>         ---help---
>           Map the 32-bit VDSO to the predictable old-style address too.
> 
>           Say N here if you are running a sufficiently recent glibc
>           version (2.3.3 or later), to remove the high-mapped
>           VDSO mapping and to exclusively use the randomized VDSO.
> 
>           If unsure, say Y.

So we need this for 32-bit glibc < 2.3.3, and we effecively have the
same problem as on 64 bits.  Next question is if those old glibcs rely
on the entry point alone or if they also expect the vdso header at that
address.

I looked at the glibc diffs from 2.3.2 to 2.3.3, but it isn't really
obvious to me what assumptions the 2.3.2 glibc made.  Perhaps Roland has
any idea?

The safest thing for that might be to have the compat vdso be a
completely separate object from the real vdso, and let the former be an
object as similar to the current one as possible.

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