On Tue, Oct 5, 2021 at 7:37 PM Camm Maguire <c...@maguirefamily.org> 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?
There are a number of differences between running 32-bit and 64-bit
kernels, and we try to limit those, but I wouldn't consider this
as one I'm worried about.
Most of the applications that abuse pointers were fixed long ago,
and there are a number of applications that actually fail on 32-bit
kernels now because they require the larger virtual address space.
> 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?
Recompiling an application to match a kernel's implementation detail
is really not how this should work. Possibly workable solutions I can
think of would include:
- coming up with a runtime detection that works across architectures
to figure out which pointer representation to use.
- reserve the upper part of the memory using a MAP_FIXED
mmap()
- drop the pointer hack altogether.
Arnd
