Re: [PATCH 3/8] seccomp: Introduce SECCOMP_PIN_ARCHITECTURE

On Wed, Jun 17, 2020 at 8:25 AM Jann Horn [off-list ref] wrote:

On Tue, Jun 16, 2020 at 9:49 AM Kees Cook [off-list ref] wrote:

quoted

For systems that provide multiple syscall maps based on architectures
(e.g. AUDIT_ARCH_X86_64 and AUDIT_ARCH_I386 via CONFIG_COMPAT), allow
a fast way to pin the process to a specific syscall mapping, instead of
needing to generate all filters with an architecture check as the first
filter action.

This seems reasonable; but can we maybe also add X86-specific handling
for that X32 mess? AFAIK there are four ways to do syscalls with
AUDIT_ARCH_X86_64:

You're out of date :)  I fixed the mess.

commit 6365b842aae4490ebfafadfc6bb27a6d3cc54757
Author: Andy Lutomirski [off-list ref]
Date:   Wed Jul 3 13:34:04 2019 -0700

    x86/syscalls: Split the x32 syscalls into their own table

1. normal x86-64 syscall, X32 bit unset (native case)
2. normal x86-64 syscall, X32 bit set (for X32 code calling syscalls
with no special X32 version)

Returns -ENOSYS now if an x32 version was supposed to be used.

3. x32-specific syscall, X32 bit unset (never happens legitimately)

Returns -ENOSYS now.

4. x32-specific syscall, X32 bit set (for X32 code calling syscalls
with special X32 version)

(I got this wrong when I wrote the notes on x32 in the seccomp manpage...)

Can we add a flag for AUDIT_ARCH_X86_64 that says either "I want
native x64-64" (enforcing case 1) or "I want X32" (enforcing case 2 or
4, and in case 2 checking that the syscall has no X32 equivalent)? (Of
course, if the kernel is built without X32 support, we can leave out
these extra checks.)

No extra checks needed.  Trying to do a syscall with a wrongly-encoded
x32 nr just generates -ENOSYS now.

Henceforth, all new syscalls will have the same number for native and
x32 and will differ only in the presence of the x32 bit.

--Andy