<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 Feb 2017 00:49, "Kees Cook" <<a href="mailto:keescook@chromium.org">keescook@chromium.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Thu, Feb 2, 2017 at 10:08 AM, Bhupesh Sharma <<a href="mailto:bhsharma@redhat.com">bhsharma@redhat.com</a>> wrote:<br>
> On Thu, Feb 2, 2017 at 7:51 PM, Kees Cook <<a href="mailto:keescook@chromium.org">keescook@chromium.org</a>> wrote:<br>
>> On Wed, Feb 1, 2017 at 9:42 PM, Bhupesh Sharma <<a href="mailto:bhsharma@redhat.com">bhsharma@redhat.com</a>> wrote:<br>
</div><div class="quoted-text">>>> The 2nd patch increases the ELF_ET_DYN_BASE value from the current<br>
>>> hardcoded value of 0x2000_0000 to something more practical,<br>
>>> i.e. TASK_SIZE - PAGE_SHIFT (which makes sense especially for<br>
>>> 64-bit platforms which would like to utilize more randomization<br>
>>> in the load address of a PIE elf).<br>
>><br>
>> I don't think you want this second patch. Moving ELF_ET_DYN_BASE to<br>
>> the top of TASK_SIZE means you'll be constantly colliding with stack<br>
>> and mmap randomization. 0x20000000 is way better since it randomizes<br>
>> up from there towards the mmap area.<br>
>><br>
>> Is there a reason to avoid the 32-bit memory range for the ELF addresses?<br>
><br>
</div><div class="quoted-text">> I think you are right. Hmm, I think I was going by my particular use<br>
> case which might not be required for generic PPC platforms.<br>
><br>
> I have one doubt though - I have primarily worked on arm64 and x86<br>
> architectures and there I see there 64-bit user space applications<br>
> using the 64-bit load addresses/ranges. I am not sure why PPC64 is<br>
> different historically.<br>
<br>
</div>x86's ELF_ET_DYN_BASE is (TASK_SIZE / 3 * 2), so it puts it ET_DYN<br>
base at the top third of the address space. (In theory, this is to<br>
avoid interpreter collisions, but I'm working on removing that<br>
restriction, as it seems pointless.)<br>
<br>
Other architectures have small ELF_ET_DYN_BASEs, which is good: it<br>
allows them to have larger entropy for ET_DYN.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Fair enough. I will drop the 2nd patch then and spin a v2.</div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Bhupesh </div><div dir="auto"><div class="gmail_extra"><br></div></div></div>