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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
