Paul Chaignon's GSoC status report - #9 of 12

[Paul Chaignon]

Hi all,

Accomplishments:
- Added support for all archs in the seccomp patchset.  There are now
  PERSONALITYX_AUDIT_ARCH constants that contain both the AUDIT_ARCH_XXX
  constant and an optional bit mask to check for archs with several
  personalities.  There's also a SECCOMP_TRACED_SYSCALLS constant for some
  archs that require a few additional syscalls to be traced (e.g., execv
  for sparc).
- Found a clean way to remove the last arch-specific constant from
  filter_seccomp.c.  x86 needs a special case as the bit mask should be
  checked in addition to the AUDIT_ARCH_XXX constant.  To handle that
  without needing to make the PERSONALITYX_AUDIT_ARCH constants more
  complex, I reversed the traversal of personalities in the BPF program.
  Thus, for x86, x32 is checked first with two conditional jumps: one for
  the AUDIT_ARCH constant (same as x86_64), and one for the bit mask.  If
  x86_64 was checked first, the PERSONALITYX_AUDIT_ARCH structs would
  need to be extended with a new field to indicate the second check to
  perform.
- Fixed a couple issues in the current, linear BPF program.
- Reworked check on size of generated program (before actual generation)
  to avoid overestimating the size of the BPF program.
- Tested support on arm.  I'm waiting for an aarch64 board to test that
  too (it's also a better test as aarch64 has several personalities).
- Finished implementing generation of bit matching BPF program.  On a
  first look, results are not as good as I expected.  For instance, for
  x86_64 personality, when tracing a single syscall (bpf(2)), linear BPF
  program has 8 instructions whereas binary match program has 35
  instructions.  It would take a large number of traced syscalls to make
  the binary match program the best choice...

Priorities:
- Send second RFC for seccomp patchset, to validate new
  PERSONALITYX_AUDIT_ARCH constants.
- Compare the two BPF programs through evaluations of sizes and speed for
  diverse archs.  cBPF doesn't have execution time statistics, so I'll
  have to write a small program to trace the execution times (or use an
  existing bcc tool if possible).  Even if the binary match program have
  bad results, I'm planning on submitting it as a future RFC patchset, for
  the record.
- Write new strategy for BPF program that reverts the syscalls to check
  (match ALLOWed syscalls instead of TRACEd syscalls).   This strategy
  would be a better fit for e.g., -e trace=!bpf.

Paul