On Sat, 11 Mar 2017, ropers wrote:
> Was 32-on-64 compatibility somehow easier to achieve on the Linux side?
> Or did they just keep throwing code and more code at the problem because
> they felt they really, really had to have this? It's that kind of idle
> curiosity. If nobody's interested in explaining or hearing this
> explained, then sorry for the noise.
There's (at least) three parts to such compat for the kernel:
1) the low-level kernel<->userspace boundary handling.
A 32-bit process has a different pmap, adding code and requiring the
uvm layer to indirect or test which is in play for its operations. The
syscall/trap interface is quite different too; amd64 is sooooo much
nicer for syscall entry and %fs/%gs handling than i386. You don't
want that shit in your nice 64bit kernel!
2) ABI mapping
So you called some syscall and it has the result to copy out to
userspace. Oh wait, which ABI is this process using, the 64bit ABI
that matches the kernel's structure layouts or a completely different
ABI that requires checking for overflow and then repacking structures
to match the 32bit ABI? Yay, we get to think about that every time we
do copyin/copyout! Let's see, 490 calls to those two functions in 119
files (not counting sys/arch/*). OSes that support this tend to
introduce an abstraction layer to reduce the number of those that are
needed, but that's still cognitive load.
3) interprocess handling
a) 64bit -> 32bit
You weren't really planning on having gdb64 and gdb32, so at least
ptrace() has to be capable to letting a 64bit process manipulate a
32bit process. Go look at FreeBSD's sys/kern/sys_process.c for
example and examine the COMPAT_FREEBSD32 blocks. They've done it,
obviously, but it's not simple, beautiful code. A comment like
* This CPP subterfuge is to try and reduce the number of ifdefs in
* the body of the code.
is a warning that feature is costing you a chunk.
b) 32bit -> 64bit
Maybe you ban 32bit ptrace() of 64bit processes (most do IIRC), but
you still want 32bit processes to be able to use sysctl(KERN_PROC)
and see 64bit processes
Implementations have jumped through all those hoops, but at what cost in
complexity and security holes, and there *have* a been a bunch! A google
search for "security hole in 32bit compat" immediately turned up this
article:
https://lwn.net/Articles/406466/
Adding "FreeBSD" or "NetBSD" to the search turns up hits for them too.
This stuff is *hard* and the benefit is...?
Nope, don't want it.
Philip Guenther
