From: Hector Marco <hecmargi@upv.es>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Ingo Molnar" <mingo@redhat.com>,
"Anton Blanchard" <anton@samba.org>,
"Jiri Kosina" <jkosina@suse.cz>,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>,
"David Daney" <ddaney.cavm@gmail.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Arun Chandran" <achandran@mvista.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
"Ismael Ripoll" <iripoll@disca.upv.es>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Hanno Böck" <hanno@hboeck.de>,
"Will Deacon" <will.deacon@arm.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Kees Cook" <keescook@chromium.org>,
"Reno Robert" <renorobert@gmail.com>
Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
Date: Fri, 19 Dec 2014 23:04:15 +0100 [thread overview]
Message-ID: <5494A0DF.10905@upv.es> (raw)
In-Reply-To: <CALCETrVAaDDvAttVkJ+1ygymE_uEZOCLtGHHN15v_VDf1PVsmA@mail.gmail.com>
El 12/12/14 a las 18:17, Andy Lutomirski escribió:
> On Dec 12, 2014 8:33 AM, "Hector Marco" <hecmargi@upv.es> wrote:
>>
>> Hello,
>>
>> I agree. I don't think a new randomization mode will be needed, just fix
>> the current randomize_va_space=2. Said other way: fixing the offset2lib
>> will not break any current program and so, no need to add additional
>> configuration options. May be we shall wait for some inputs
>> from the list (may be we are missing something).
>>
>>
>> Regarding to VDSO, definitively, is not randomized enough in 64bits.
>> Brute force attacks would be pretty fast even from the network.
>> I have identified the bug and seems quite easy to fix it.
>>
>> On 32bit systems, this is not a issue because it is mapped in the
>> mmap area. In order to fix the VDSO on 64bit, the following
>> considerations shall
>> be discussed:
>>
>>
>> Performance:
>> It seems (reading the kernel comments) that the random allocation
>> algorithm tries to place the VDSO in the same PTE than the stack.
>
> The comment is wrong. It means PTE table.
>
>> But since the permissions of the stack and the VDSO are different
>> it seems that are getting right the opposite.
>
> Permissions have page granularity, so this isn't a problem.
>
>>
>> Effectively VDSO shall be correctly randomized because it contains
>> enough useful exploitable stuff.
>>
>> I think that the possible solution is follow the x86_32 approach
>> which consist on map the VDSO in the mmap area.
>>
>> It would be better fix VDSO in a different patch ? I can send a
>> patch which fixes the VDSO on 64 bit.
>>
>
> What are the considerations for 64-bit memory layout? I haven't
> touched it because I don't want to break userspace, but I don't know
> what to be careful about.
>
> --Andy
I don't think that mapping the VDSO in the mmap area breaks the
userspace. Actually, this is already happening with the current
implementation. You can see it by running:
setarch x86_64 -R cat /proc/self/maps
Do this break the userspace in some way ?
Regarding the solution to the offset2lib it seems that placing the
executable in a different memory region area could increase the
number of pages for the pages table (because it is more spread).
We should consider this before fixing the current implementation
(randomize_va_space=2).
I guess that the current implementation places the PIE executable in
the mmap base area jointly with the libraries in an attempt to reduce
the size of the page table.
Therefore, I can fix the current implementation (maintaining the
randomize_va_space=2) by moving the PIE executable from the mmap base
area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do).
But we shall agree that this increment in the page table is not a
issue. Otherwise, the randomize_va_space=3 shall be considered.
Hector Marco.
>
>>
>>
>> Regards,
>> Hector Marco.
next prev parent reply other threads:[~2014-12-19 22:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5489E6D2.2060200@upv.es>
2014-12-11 20:12 ` [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack Hector Marco
2014-12-11 22:11 ` Kees Cook
2014-12-12 16:32 ` Hector Marco
2014-12-12 17:17 ` Andy Lutomirski
2014-12-19 22:04 ` Hector Marco [this message]
2014-12-19 22:11 ` Andy Lutomirski
2014-12-19 22:19 ` Cyrill Gorcunov
2014-12-19 23:53 ` Andy Lutomirski
2014-12-20 0:29 ` [PATCH] x86_64, vdso: Fix the vdso address randomization algorithm Andy Lutomirski
2014-12-20 17:40 ` [PATCH v2] " Andy Lutomirski
2014-12-20 21:13 ` Kees Cook
2014-12-22 17:36 ` [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack Hector Marco Gisbert
2014-12-22 17:56 ` Andy Lutomirski
2014-12-22 19:49 ` Jiri Kosina
2014-12-22 20:00 ` Andy Lutomirski
2014-12-22 20:03 ` Jiri Kosina
2014-12-22 20:13 ` Andy Lutomirski
2014-12-22 23:23 ` Hector Marco Gisbert
2014-12-22 23:38 ` Andy Lutomirski
[not found] ` <CAH4rwTKeN0P84FJnocoKV4t9rc2Ox_EYc+LEibD+Y83n7C8aVA@mail.gmail.com>
2014-12-23 8:15 ` Andy Lutomirski
2014-12-23 20:06 ` Hector Marco Gisbert
2014-12-23 20:53 ` Andy Lutomirski
2015-01-07 17:26 ` Hector Marco Gisbert
2014-12-05 0:07 Hector Marco
2014-12-05 20:08 ` Kees Cook
2014-12-08 22:15 ` Hector Marco Gisbert
2014-12-05 22:00 ` Andy Lutomirski
2014-12-08 20:09 ` Christian Borntraeger
2014-12-09 17:37 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5494A0DF.10905@upv.es \
--to=hecmargi@upv.es \
--cc=achandran@mvista.com \
--cc=akpm@linux-foundation.org \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=ddaney.cavm@gmail.com \
--cc=hanno@hboeck.de \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=iripoll@disca.upv.es \
--cc=jkosina@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=renorobert@gmail.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).