Re: armv8 does not respect personality ADDR_LIMIT_3GB
On Tue, Oct 05, 2021 at 01:37:49PM -0400, Camm Maguire wrote:
> Greetings, and thank you so much for your very detailed, clear, and
> comprehensive reply!
>
> PER_LINUX_32GB and/or a userspace interface to set the address space
> layout would be nice, but my chief concern is that whatever the kernel
> provides to userspace be the same on all machines purporting to be of
> the same 'architecture'. On further investigation, it appears that
> 32bit arm(el)(hf) kernels have a 3GB address space, starting the stack
> at 0xbfffffff, regardless of the PER_LINUX_32GB personality setting, and
> that 32bit compatibility mode on a 64bit kernel provides a 4GB address
> space, starting the stack at 0xffffffff, again regardless of
> personality, as you state. To me it seems that the 64bit kernel, if it
> offers a compatibility mode, should match whatever the contemporaneous
> 32bit kernel behavior is, making this a bug in the compatibility mode.
>
> Even if this is not deemed a bug, 32bit chroot under 64bit is
> effectively a different architecture at present. I suggest that
> arm(el)(hf) refer to a genuine 32bit kernel, whatever address space it
> chooses to provide, and that therefore as long as this difference is
> outstanding, some method in buildd be provided to allow packages to
> specify that they should only be built in a 'true' environment. Might
> this be possible?
>
> I can put a runtime check in gcl to detect such a mismatch and exit with
> an explanatory message for the (hopefully) unlikely case that some
> non-developer user wants to run these 32bit binaries under a 64bit
> kernel in chroot.
>
> If/when the 32bit address space goes to 3.75GB, that will necessitate a
> recompile, but as long as consistency is maintained 32bit binaries can
> be distributed and expected to run on machines of the same
> 'architecture'.
>
> Your thoughts?
Seems to me that gcl is making assumptions that are invalid. Like
assuming the stack start location at compile time will forever be valid.
Or assuming that there is any address space free above the stack.
I don't think any linux architecture ABI has ever made such a promise.
So it seems to me that gcl is simply wrong and should be rewritten
properly. Looks like a potentially large job.
>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
randomization, can you really ever be sure that there will be a part of
address space that isn't used? Code really should stop trying to abuse
bits in pointers for their own purposes. It always ends up breaking no
matter how clever they people that came up with it thought they were at
the time.
--
Len Sorensen
Reply to: