linux-kernel - Re: [PATCH v2 0/2] x86: Relocate the compat vdso per process

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: <CALCETrWAz=gVWpsCTcy=Y=Bh7PL9iPwGgUbUsBkMbsiyh3hyYQ@mail.gmail.com>
Date:	Wed, 12 Mar 2014 09:20:50 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>, X86 ML <x86@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Jones <davej@...hat.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>,
	Andi Kleen <andi@...stfloor.org>,
	Stefani Seibold <stefani@...bold.net>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>
Subject: Re: [PATCH v2 0/2] x86: Relocate the compat vdso per process

On Tue, Mar 11, 2014 at 11:14 PM, H. Peter Anvin <hpa@...or.com> wrote:
> There is one sensible address: end of address space perhaps minus some small offset.  Unlikely to be used by anything specific.

Meh.  The compat vdso logic will end up being either:

1) Try to map at the preferred address.  If it fails, don't map it.
Force ASLR off for the vdso

2) Try to map at the preferred address.  If it fails, map somewhere
else and relocate.

3) Try to map at the preferred address unless ASLR is on.  If it fails
or ASLR is on, map somewhere else and relocate.

since the whole point is to simplify this stuff, I don't really like
any of these choices.  That's a lot of code to save 4k per process,
and when it breaks (which I suspect it will the next time anyone
touches the address space layout) so one will notice that 4k gets
wasted again.

>
> On March 11, 2014 11:09:11 PM PDT, Andy Lutomirski <luto@...capital.net> wrote:
>>On Mar 11, 2014 10:02 PM, "H. Peter Anvin" <hpa@...or.com> wrote:
>>>
>>> On 03/11/2014 03:15 PM, Andy Lutomirski wrote:
>>>>
>>>> The meat of this patch series is in patch 1.  Patch 2 is split out
>>for
>>>> improved bisectability.
>>>>
>>>> Changes from v1: Split into two patches and fixed a comment.
>>>>
>>>> Andy Lutomirski (2):
>>>>    x86: Dynamically relocate the compat vdso
>>>>    x86_32: Remove user bit from identity map PDE
>>>>
>>>>   Documentation/kernel-parameters.txt  |  18 +++-
>>>>   arch/x86/Kconfig                     |  24 +++--
>>>>   arch/x86/include/asm/elf.h           |   4 -
>>>>   arch/x86/include/asm/fixmap.h        |   8 --
>>>>   arch/x86/include/asm/pgtable_types.h |   7 +-
>>>>   arch/x86/include/asm/vdso.h          |   5 +-
>>>>   arch/x86/vdso/vdso-layout.lds.S      |   2 +-
>>>>   arch/x86/vdso/vdso32-setup.c         | 173
>>++++++++++++++++-------------------
>>>>   arch/x86/vdso/vdso32/vdso32.lds.S    |   2 -
>>>>   9 files changed, 111 insertions(+), 132 deletions(-)
>>>>
>>>
>>> Why per process?  *If* we have compat vdso turned on, can't we just
>>put it in one place system-wide?
>>
>>My machine has ASLR turned on, and the vma really does end up
>>somewhere different each time.  I suspect that most (?) ASLR users
>>would happily accept the 4k hit to keep ASLR working fully.
>>
>>Another downside of trying to have a common address for all processes:
>>someone needs to figure out what that address is.  What happens if an
>>ELF binary (or interpreter) wants to load something at the chosen
>>address?
>>
>>--Andy
>
> --
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/