[$] The inherent fragility of seccomp()

By corbet Kernel developers have worried for years that tracepoints could lead to
applications depending on obscure implementation details; the consequent
need to preserve existing behavior to avoid causing regressions could end
up impeding future development. A recent report shows that the
seccomp() system call is also more prone to regressions than users
may expect — but kernel developers are unlikely to cause these regressions
and, indeed, have little ability to prevent them. Programs using
seccomp() will have an inherently higher risk of breaking when
software is updated.

From: LWN