GNU bug report logs -
#43513
readdir misbehaves when running 32-bit user space on a 64-bit-kernel - kernel/userspace interface mismatch in getdents64
Previous Next
Full log
Message #22 received at 43513 <at> debbugs.gnu.org (full text, mbox):
Hi Danny!
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> I found the underlying cause of the problem with qemu transparent emulation:
>
> * qemu transparent emulator has 64 bit registers
> * the thing it's emulating has 32 bit registers
> * The glibc in the distro that is running in the emulator is using getdents64
> (on 32 bits!) and then (rightfully) checking whether d_off and the inode number
> fit into their own (32 bits/entry) struct, which they don't (the thing they get
> from the kernel is 64 bits/entry).
Looks very much like the CMake-on-emulated-hardware issue several of us
encountered before:
https://issues.guix.gnu.org/38454#3
https://issues.guix.gnu.org/42448
Glad you found an explanation!
(I see you also posted <https://issues.guix.gnu.org/43591>.)
> See also https://lore.kernel.org/lkml/20181229015453.GA6310 <at> bombadil.infradead.org/T/
> for an analysis.
>
> See also https://sourceware.org/bugzilla/show_bug.cgi?id=23960 for a discussion.
Woow.
> Least-shitty workaround: Use a 32-bit qemu (yes, a qemu compiled on 32 bit)
> on a 64 bit machine for transparent emulation of ANOTHER 32-bit machine.
> That way, the kernel can know that there's a 32 bit user lurking somewhere up
> the call chain that is calling getdents64 and is not actually able to process the
> result. "The truth? It can't handle the truth."
OK.
> The right fix: One could also tell all the packages in the emulated
> system to use the large file size API (-D_FILE_OFFSET_BITS=64 and co). In this
> case cmake is affected--but it could be any number of things. I think that that
> is the only good fix (we could also add a compile-time check whether <dirent.h>
> has been included without anyone specifying -D_FILE_OFFSET_BITS=64--that would
> make finding these problems a LOT easier; if possible, emit that compile-time
> error only if readdir is actually called anywhere).
Yes; that user-space should be built with -D_FILE_OFFSET_BITS=64 is also
the conclusion at
<https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c32>.
Let’s fix CMake (and JSON-C?) in ‘core-updates’ or ‘staging’ (using a
graft for CMake wouldn’t help because CMake is used at build time.)
> +(define (closest-cross-compiled-qemu qemu target-bits)
> + "Cross-compile QEMU for the given TARGET-BITS platform that is closest to
> +the actual host architecture, if possible. This is in order to prevent
> +https://lore.kernel.org/lkml/20181229015453.GA6310 <at> bombadil.infradead.org/T/"
> + (define (cross-compiled-qemu target)
> + (package
> + (inherit qemu)
> + (arguments
> + (substitute-keyword-arguments (package-arguments qemu)
> + ((#:configure-flags flags)
> + `(cons ,(string-append "--cross-prefix=" target "-")
> + ,flags))))
> + (native-inputs
> + `(("cross-gcc" ,(cross-gcc target))
> + ("cross-binutils" ,(cross-binutils target))
> + ,@(package-native-inputs qemu)))))
> + (match target-bits
> + (64 qemu)
> + (32 (match (register-width (%current-system))
> + (32 qemu)
> + (64 (match (%current-system)
> + ("x86_64-linux"
> + (cross-compiled-qemu (nix-system->gnu-triplet "i686-linux")))
> + ("aarch64-linux"
> + (cross-compiled-qemu "arm-linux-gnueabihf"))
> + (_ (begin
> + ;; TODO: Print warning
> + qemu))))))))
It doesn’t make sense to cross-compile from x86_64 to i686. Instead we
should use a native build, but an i686 one:
(package/inherit qemu
(arguments `(#:system "i686-linux" ,@(package-arguments qemu))))
Likewise for AArch64/ARMv7.
How does that sound?
Thanks,
Ludo’.
This bug report was last modified 4 years and 317 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.