From: Jiri J. <jja...@re...> - 2014-08-07 08:28:46
|
On 08/06/2014 09:40 PM, Linda Knippers wrote: > Hi Jiri, > > On 8/5/2014 12:35 PM, Jiri Jaburek wrote: >> On 07/28/2014 03:33 PM, Jiri Jaburek wrote: >>> (A) is a bit problematic, since we would need to come up with a full >>> logic of what syscalls to compile on what architectures. We already >>> do that on some level, but this option calls for a separate mapping >>> file (or so) instead of simple Makefile-based conditions, >>> integrating it somehow into the make system. >>> >> >> Mapping file syntax concept (quick draft): >> >> <line>: <syscall> | <syscall><separator><archlist> >> <syscall>: (syscall name, any non-whitespace string) >> <separator>: (any non-LF whitespace) >> <archlist>: <neg><archspec> | <neg><archspec>,<archlist> >> <neg>: ! | (empty) >> <archspec>: <arch> | <arch>:<bits> >> <arch>: (uname -m output, any non-whitespace string) | all >> <bits>: 32 | 64 >> >> The logic would go through the <archlist> from left to right, >> ending the search on first matching expression. >> Empty <archlist> would imply "relevant everywhere". >> >> In the following example, "use" means "compile/run/audit": >> (comments not included in syntax definition here) >> >> # use everywhere >> accept >> # same as above >> accept4 all >> # never use >> access !all >> # use everywhere (leftmost precedence) >> acct all,!all > > I get this one, but would hope to never see it. Example, used just to demonstrate the logic, never to be realistically used as it doesn't make sense. > >> # never use (leftmost precedence) >> add_key !all,all > > This one confusing me, so I really hope to never see it. > In fact, I'm confused by "all" and "!all" in places. In > some cases, it seems like "all" is implied but in other cases, > it's not. Example, see above. > >> # use everywhere, but only on 64bits >> adjtimex all:64 >> # don't use on 32bit anywhere >> afs_syscall !all:32 > > Does that mean that "all" or "all:64" are implied? It means that anything except 32bit architectures is implied, which is - in the current concept - all:64, but might as well be all:128. :) > >> # use only on s390x and ppc64 >> alarm s390x,ppc64 > > But here, nothing about "all" is implied. > >> # same as above >> arch_prctl s390x,ppc64,!all > > Oh, but "!all" is implied? Example, see above. > >> Some practical examples: >> >> # not on s390x, everywhere on ppc64, others only non-32bit >> bind !s390x,ppc64,!all:32 > > So all:64 is implied. > >> # alternative specification of the above, more explicit >> socket !s390x,ppc64,x86_64 > > x86_64 means not 32? x86_64 supports 32-bit syscalls on a 64-bit > kernel, which is different than just x86, which is just a 32-bit > arch? > >> # everywhere but 64bit x86_64 >> socketcall !x86_64:64 >> >> Existing rules from utils/bin/Makefile (some of the special cases): >> >> clone2 ia64 >> # in Makefile as "ONLY86", but in fact this >> fork !s390x,!ppc64,!ia64,!aarch64 >> vfork !s390x,!ppc64,!ia64,!aarch64 >> # ugh, duplications in Makefile >> mmap2 ppc64:32,s390x:32,all:32 >> uselib ppc64:32,s390x:32,all:32,all > > Does that one really mean all? >> >> (most of the arch-specific syscalls are missing here, probably due to >> most wrappers using glibc) >> >> I've tried to make it as simple / readable as possible. >> Please note that this is just a draft in case we go with (A), showing >> more realistically how it would look. > > Yes, thanks. It's really helpful to have concrete examples to > consider. >> >> As for the "useless" lines having just the syscall name - we definitely >> want these to remain, since they assert that the syscall is being >> tested. Autodetecting anything not on the list wouldn't ensure that. > > After reading all this, I would think that a line with just the syscall name > would mean we know there is a syscall but we're not testing it, unless "all" > is implied, but I think that's confusing. > I may have incorrectly explained the logic, basically: - if archlist is missing, the syscall is relevant everywhere - if archlist is specified, the syscall is relevant only to architectures specified in archlist - the archlist is parsed from left to right and the first "matching" archspec is used (think: iptables rules) Eg. the difference for an Intel system reading syscall1 "ppc64" syscall2 "ppc64,!s390x" is that syscall1 never matches (x86_64 == ppc64 is false), but syscall2 does, (x86_64 == ppc64 || x86_64 == !s390x is true). Some more examples from the point of view of x86_64 using an alternate pseudocode: >> bind !s390x,ppc64,!all:32 (x86_64 not in (s390x) || x86_64 in (ppc64) || x86_64 not in (all:32)) would match on the first comparison >> mmap2 ppc64:32,s390x:32,all:32 (x86_64 in (ppc64:32) || x86_64 in (s390x:32) || x86_64 in (all:32)) would match on the third comparison if MODE is 32 >> uselib ppc64:32,s390x:32,all:32,all (x86_64 in (ppc64:32) || x86_64 in (s390x:32) || x86_64 in (all:32) || x86_64 in (all)) would match on the third comparison if MODE is 32, match on the fourth comparison otherwise I'm open to modifications of the logic, I guess we could make the inclusion more explicit, so that "!s390x" wouldn't mean anything without "all" after it, adding explicit "all" on all lines, my original design was to be more inclusive by default (and make use of !<arch> to exclude architectures that are known to not have the syscall). Jiri |