[Bug 2590] Seccomp filter for missing architectures

[bugzilla-daemon at bugzilla.mindrot.org]

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

--- Comment #6 from Joshua Kinard <kumba at gentoo.org> ---
(In reply to Darren Tucker from comment #5)
> (In reply to Joshua Kinard from comment #3)
> > 
> > I hate to reopen, but I found a corner case for MIPS broken by the
> > MIPS whitelist.  Specifically, the proposed whitelist does not
> > account for MIPS N32 ABI (under mips64).
> > 
> > Specifically:
> > +	mips64-*)
> > +		seccomp_audit_arch=AUDIT_ARCH_MIPS64
> > 
> > There needs to be another hook to somehow detect N32 and then set
> > either AUDIT_ARCH_MIPS64 (big-endian) or AUDIT_ARCH_MIPSEL64N32
> > (little-endian).
> 
> what does configure.guess report on such systems?  If that's not a
> reliable indicator, what is?  mips64-* && AC_CHECK_SIZEOF([int],
> [4]) ?

config.guess reports back "mips64-unknown-linux-gnu", which is my
system CHOST value (Gentoo, SGI Octane).  It does the same in an O32
chroot, so this might be unreliable.  O32 Linux userlands require a
CHOST of "mips-unknown-linux-gnu", even when run under a mips64 kernel.

Per the MIPS N32 handbook, you can tell O32/N32 apart from N64 (full
64-bit) by checking the size of a pointer, which should be 8 bytes on
N64.  But it'll be 4 bytes under both O32/N32, so this approach won't
work either.

Is it possible to have configure compile a test binary using the
provided C compiler and flags, then check the file magic of the output
binary?  That's a definitive way to differ between all three ABI's (and
may even be applicable for multilib setups).  I scanned briefly through
the autoconf manual, but I don't see a built-in check for this.

O32 /bin/cat:
/bin/cat: ELF 32-bit MSB executable, MIPS, MIPS-IV version 1 (SYSV),
dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32,
stripped

N32 /bin/cat:
/bin/cat: ELF 32-bit MSB executable, MIPS, N32 MIPS-IV version 1
(SYSV), dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux
2.6.32, stripped

So a check for the presence of "N32" in file's output would be enough
to detect between O32 and N32.

Should you ever get around to supporting X32 on the Intel/AMD
platforms, this same situation is bound to come up again.  X32 either
copies, or was inspired by, N32 and so they aim to achieve similar
goals.

-- 
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.