On Wed, Jun 7, 2017 at 2:29 AM, Michael Ellerman wrote:
> Daniel Micay writes:
>
>> Rather than doing this, the base should just be split for an ELF
>> interpreter like PaX.
>
> I don't quite parse that, I think you mean PaX uses a different base for
> an ELF interpreter vs a regular ET_DYN?
>
>
On Wed, Jun 7, 2017 at 2:59 PM, Michael Ellerman wrote:
> Daniel Micay writes:
>
>> Rather than doing this, the base should just be split for an ELF
>> interpreter like PaX.
>
> I don't quite parse that, I think you mean PaX uses a different base for
> an ELF interpreter vs a regular ET_DYN?
I a
Daniel Micay writes:
> Rather than doing this, the base should just be split for an ELF
> interpreter like PaX.
I don't quite parse that, I think you mean PaX uses a different base for
an ELF interpreter vs a regular ET_DYN?
That would be cool. How do you know that it's an ELF interpreter you'r
Rather than doing this, the base should just be split for an ELF
interpreter like PaX. It makes sense for a standalone executable to be
as low in the address space as possible. Doing that ASAP fixes issues
like this and opens up the possibility of fixing stack mapping ASLR
entropy on various archit
Since 7e60d1b427c51cf2525e5d736a71780978cfb828, the ELF_ET_DYN_BASE
for powerpc applications has been set to 512MB.
Recently there have been several reports of applications SEGV'ing
and newer version of glibc also SEGV'ing (while testing) when using the
following
test method:
LD_LIBRARY_PATH
5 matches
Mail list logo
