Problem Reveal

Recently I examined seccomp filter in chromium and found it had a value in act TRAP.

I'm using a cooperated seccomp tool called ceccomp with ceccomp trace --pid=4187 to dump the filter in browsers, from which I take a screenshot. In the screenshot, line 604 ends with 0x00030001, where the last 1 is data. To confirm that truly works, I checked out manual:

SECCOMP_RET_TRAP
This value results in the kernel sending a thread-directed
SIGSYS signal to the triggering thread. (The system call
is not executed.) Various fields will be set in the
siginfo_t structure (see sigaction(2)) associated with
signal:

• si_signo will contain SIGSYS.

• si_call_addr will show the address of the system call
  instruction.

• si_syscall and si_arch will indicate which system call
  was attempted.

• si_code will contain SYS_SECCOMP.

• si_errno will contain the SECCOMP_RET_DATA portion of
  the filter return value.

The program counter will be as though the system call
happened (i.e., the program counter will not point to the
system call instruction). The return value register will
contain an architecture-dependent value; if resuming
execution, set it to something appropriate for the system
call. (The architecture dependency is because replacing it
with ENOSYS could overwrite some useful information.)

I also read kernel source code and found the data truly works. Tracking back kernel versions, the kernel had enabled this feature since v3.

Bug Found

Now talk back about libseccomp, it exposes an API to allow users to determine what action when performing the filter. SCMP_ACT_ERRNO and SCMP_ACT_TRACE are two macros which accept a uint16_t data, while SCMP_ACT_TRAP is only a constant.

According to exploration above, SCMP_ACT_TRAP should also take data like SCMP_ACT_ERRNO or SCMP_ACT_TRACE.

Two Choices

This is definitely a flaw and need to be fixed. However, should we make a breaking change?

• Refactor SCMP_ACT_TRAP to SCMP_ACT_TRAP(x), which keeps behavior like errno or trace, but may break downstream softwares.
• Add a new macro like SCMP_ACT_TRAPX(x) to accept the value, which have no impact on compatibility, but may be confusing for users to have a similar SCMP_ACT_TRAP.

I would like to make contributions and this is my main concern. Which proposal will you suggest?