Re: armv8 does not respect personality ADDR_LIMIT_3GB
On Wed, Oct 06, 2021 at 02:08:49PM -0400, Camm Maguire wrote:
> Greetings, and thanks for your reply
>
> On Tue, 5 Oct 2021 15:01:59 -0400, Len Sorensen wrote:
>
> >>From what I could find, some programs allocate their own stack early in
> >execution and can hence put it where they want which I guess would free
> >up some known address space range. Potentially. With address space
>
> Might you please provide an explicit reference for this?
I can't seem to find the page I read, but it seems that you might be
able to use clone() to create a new process with a stack you allocated.
So if you can somehow allocate a stack at a lower address and then
clone() to switch to a process with that stack, and reserve the memory
range you want to abuse, and check that it was able to (after all with
address space randomization it doesn't have to work if you ask for a
specific address), then you could probably get away with things after
that by using that reserved range for the fixnum stuff. But it would
probably need different handling for 32 and 64 bit machines, and would
have to do this all at runtime of course, since there is no promise of
what size of address space the kernel will give you. I see arm has 1G,
2G, 3G and possibly others. What you build on is certainly not any
indication of what you might run on. If I recall correctly the page I
read was someone trying to do this in virgil.
There really doesn't seem to be any way to ensure you can abuse a
certain range of the address space, beacuse well, you are abusing it.
It's not proper coding and not something linux ever promised you could do.
x86 being one of the first 32/64 bit dual architectures added the 3GB
workaround to help out code while it got fixed up. But it seems no other
architectures later did the same since it wasn't meant to be a solution,
just a workaround.
I also get the impression in my searching for stuff about this problem,
that 3/4 of the things I find about wanting to do this are gcl related.
I guess it may be the only major offender really left that anyone uses
at all. Seems everything else either gave up, or actually fixed their
code.
--
Len Sorensen
Reply to: