[Bug 3085] seccomp issue after upgrading openssl

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3085

mirabilos <tg at debian.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---
                 CC|                            |tg at debian.org

--- Comment #30 from mirabilos <tg at 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.