On Wed, May 16, 2018 at 1:19 AM Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> wrote: > > This series enables AARCH64 with ILP32 mode. > > As supporting work, it introduces ARCH_32BIT_OFF_T configuration > option that is enabled for existing 32-bit architectures but disabled > for new arches (so 64-bit off_t userspace type is used by new userspace). > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64. A few thoughts: 1. I've never been able to shake the feeling that x32 should not need kernel support at all. As far as I can tell, the kernel support is an enormous amount of code and complexity to deal with exactly two issues. First, ILP32 only has 32-bit pointers, so there needs to be a way to tell the kernel to only use the lower 4 GB of user address space. That part is easy. Second, ILP32 user code is highly unlikely to end up with the same struct layout as ILP64 code. The latter seems like it should be solved entirely in userspace by adding a way to annotate a structure as being a kernel ABI structure and getting the toolchain to lay it out as if it were ILP64 even though the target is ILP32. 2. I think you should make a conscious decision as to whether the ILP32-ness of a syscall is a property of the task or of the syscall. On x86, x32-ness is a property of the syscall, but historically it also got rather entangled with the state of the task, and the result was a mess. It looks like you're making it be a property of the task, which is fine, but you're making it impossible for very clever ILP32 libraries to include little ILP64 stubs that do fancy things with full 64-bit syscalls. 3. Make very certain that you aren't exploitable by malicious processes that set the high bits in ILP32 syscall args. x86 compat has issues like that in the past.
