https://bugzilla.mindrot.org/show_bug.cgi?id=3085
mirabilos <t...@debian.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- CC| |t...@debian.org --- Comment #30 from mirabilos <t...@debian.org> --- I’m afraid commit 5b56bd0affea7b02b540bdbc4d1d271b0e4fc885 is completely bogus and must be reverted. Let me first clarify a few things regarding x86 systems. We have three architectures that belong to the x86 group of architectures: - i386 (the original), 32-bit CPU, 32-bit instructions, ILP32 addressing model #if defined(__i386__) kernel + userland GNU: i386-linux-gnu - amd64 (“x86_64”), 64-bit CPU, 64-bit instructions, LP64 addressing model #if defined(__x86_64__) && !defined(__ILP32__) GNU: x86_64-linux-gnu kernel + userland - x32 (amd64ilp32), 64-bit CPU, 64-bit instructions, ILP32 addressing model #if defined(__x86_64__) && defined(__ILP32__) GNU: x86_64-linux-gnux32 userland only (I think the BSD equivalent would be MACHINE=x32 MACHINE_ARCH=amd64 for x32.) Now, the amd64 Linux kernel can run *all three* kinds of machines: - amd64 ELF64 binaries (native to the amd64 kernel) - amd64 ELF32 binaries (a.k.a. x32 binaries) - i386 ELF32 binaries (native to the i386 kernel) This introduces two new problems: • “uname -m” prints x86_64 on an amd64 kernel, no matter what the userland architecture is ⇒ people running “32-bit” applications on a “64-bit” kernel (such as the initial reporter of this issue) need to run them under the “linux32” tool, which fixes up uname: $ uname -m; linux32 uname -m x86_64 i686 The reporter could also have used --build=i386-linux-gnu to force configure to end up in the correct switch case, but using linux32 in these cases is the generally accepted correct solution (any errors from not doing so are normally closed as user mistake); I even have (very old) VMs running with i386 userland and amd64 kernel where I made /sbin/init into this shell script: #!/bin/sh exec /usr/bin/linux32 /sbin/init.real "$@" • GNU autofools’ config.guess does not detect x32 correctly; they recently forbade use of $CPP for detection, for some reason, but asking the selected compiler for those predefined macros I noted above is the *only* reliable way to do that, so on x32 users (or generic build system wrappers) need to *always* pass --build=x86_64-linux-gnux32 to DTRT (Debian does this) In short, the reporter did not run x32 but i386 (userland) on their amd64 kernel. People saying “32 bit” generally (as in, 99.999% safe) mean i386, not x32 (because x32 is so special¹ people say x32 there). ① x32 “breaks up” the conventional 32-bit/64-bit mode of thinking; this is not unique (there’s an amd64ilp32 out there which is ARMv8 ILP32 userland, 64-bit instructions) nor new (MIPS has o32/n32/n64, and n32 is also kind of a “64-bit” mode but ILP32), but it’s the first, TTBOMK, to be a userland-only architecture 8.4p1 now mis-detects x32 as i386 for seccomp architecture; on x32, it must be AUDIT_ARCH_X86_64 like on amd64 (x32 is handled, in the sandbox, by checking for __ILP32__). This completely breaks openssh on x32. My advice is to revert the commit and have the original reporter use the linux32 wrapper around their i386 system. In fact, if seccomp_audit_arch is used in C code _only_ I’d even suggest to let the preprocessor determine it, not autoconf. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs