linux-kernel - Re: [PATCH v2] x86: Remove compat vdso 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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 11 Mar 2014 09:45:52 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stefani Seibold <stefani@...bold.net>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Dave Jones <davej@...hat.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>
Subject: Re: [PATCH v2] x86: Remove compat vdso support

On Tue, Mar 11, 2014 at 9:42 AM, H. Peter Anvin <hpa@...ux.intel.com> wrote:
> On 03/11/2014 09:30 AM, Linus Torvalds wrote:
>>
>> No, the trivial solution is to stop adding crap to it.
>>
>> And no, "just reserve a little more space for it" is neither trivial
>> nor a good idea. The fixed VDSO address is very much at the top of the
>> address space, so you can't allocate more space for it unless you do
>> one of
>>
>>  (a) make it non-contiguous
>>  (b) get rid of the hole that is the very last page
>>  (c) mess with the vsyscall pages and make it contiguous "backwards"
>>
>> all of which sound like *horrible* ideas. Certainly not "trivial solution".
>>
>> No, the trivial solution is to not mess with that legacy page at all.
>>
>> Why is *that* trivial solution not on the table? Why the heck are
>> people hell-bent on changing this stupid legacy page around?
>>
>> I find this whole thread very annoying. We shouldn't care about
>> x86-32, and certainly not from a performance angle - we should
>> consider it a "it's done, don't touch it" issue.
>>
>
> Andy actually did the research, and found that even the legacy VDSO
> doesn't have to live at any one particular address, it just has to live
> at the address it is linked at.  So we can move it just fine, but we
> have to change the link address to match.
>
> That gives us a lot more maneuvering room than saying it has to be at
> one specific address.
>

We could even just relocate the damn thing wherever it ends up.  That
will waste one page of memory per process, though.

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