[RFC] Syntax Proposal for Seccomp Filters in Upstart

[Steve Langasek]

On Tue, Dec 18, 2012 at 12:18:35AM +0100, David Gaarenstroom wrote:
> > I think that allowing the specification of an errno as a numeric rather than a
> > symbol should be avoided if possible. So, 'EACCESS' is fine, but allowing '13'
> > to represent nominally the same value is potentially ambiguous.

> I'd allow a number as a fall-back, but I'd prefer the textual errno
> just as much as you do, but it may not cover all possible errno's. The
> seccomp BPF allows a larger scale of numeric values (0-0x1FFF as far
> as I know, beyond that seccomp gets weird even though there's room for
> an unsigned 16-bit value)...

I think that by definition, "all possible errnos" have symbolic names.  If
you don't have a symbolic name, it's not a valid value for errno and we
should not be concerned about returning it as part of a seccomp filter
because doing so causes the kernel to violate its API.

Combined with the fact that, as mentioned, errno numeric values are not
portable across architectures, I think it's better to just prohibit them
outright rather than allow users to write jobs that will behave in
unexpected manners.

> I can imagine that when the kernel API changes, a program or libraries
> such as libc may first try to probe a syscall existence by passing the
> syscall-number and look at errno whether or not it failed or look at
> the kernel version and not even try... I'm going to have to find such
> an example first. And I don't know how likely the kernel is going to
> add new syscalls that really interfere and how soon these changes are
> supported by new software, I'll try to find out...

There are many instances where glibc will compile in fallback support for
different implementations in the absence of a particular (recently-added)
syscall.  Indeed, glibc has an explicit configure option, --enable-kernel,
to specify the minimum kernel version you want to enable support for (i.e.,
how much fallback support to build in).

> I did look at arch/x86/syscalls/syscall_*.tbl and
> include/asm-generic/unistd.h and arch/x86/include/asm/seccomp*.h
> (which seem to be the only include files containing #defines for (x86
> related) syscall numbers) and it seems these changed in the past:
> "__NR_kcmp" was added in linux-3.5
> "__NR_process_vm_readv" and "__NR_process_vm_writev" were added in linnux-3.2
> "__NR_sendmmsg" was added in linux-3.0

> The __NR_kcmp is indeed unknown in Ubuntu 12.04LTS amd64, running a
> 3.6.10 kernel.

> Anyway, just like with errno we could also allow a numeric value as
> fall-back for future syscalls, I hope that addresses your concerns?

syscall numbers are even less portable than errno.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121217/0d38b558/attachment.pgp>