Re: [Audit-test-developer] [design] How to write / run / audit syscall wrappers?

[Miroslav V. <mva...@re...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 08/11/2014 11:05 AM, Jiri Jaburek wrote:
> On 08/11/2014 07:17 AM, Miroslav Vadkerti wrote:
>> Hi,
>> 
>>> 
>>> - 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).
>> 
>> That syscall2 example is confusing. Effectively it is the same as !s390x isn't it?
> 
> Yes, I should have chosen more "valid" rules, but my point was to illustrate the first-match 
> logic on expressions.
> 
>> 
>>> 
>>> 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
>> 
>> Again, isn't this effectively !s390x? AFAICS i386 for example gets in because of the first 
>> expression. Or does using all imply this logic?
>> 
>> (arch not in s390x or arch in ppc64) and arch not 32bit?
> 
> Indeed, i386 (like anything 32bit/64bit, which is not s390x) would match the first rule.
> 
>> 
>> BTW does s390x mean both s390x:64, s390x:32?
> 
> It means "disregard MODE", meaning 64, 32 or any other value.
> 
>> 
>>> 
>>>>> 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).
>> 
>> Why would not be good to add and between the expressions and except all only for inclusion?
>> 
>> So for example
>> 
>> all:32,!i386 could mean everything 32bit except i386
> 
> How would you specify, for example, "only s390x and ppc64"? (arch == s390x && arch == ppc64) 
> never matches.

Yep, that would be obscure via negation. So maybe switch to and
logic only if 'all' specified. But I got less thinking to this than you, so
I will now let this thoughts be :)

> 
>> 
>> The current proposal seems quite confusing to me. I reread the previous email also but it 
>> didn't help.
> 
> The idea was to create a simple and easy-to-understand syntax. If it's confusing, then it's
> not what I was looking for.
> 
> What about using the explicit approach that Linda pointed out? Ie.
> 
> # run only on s390x and ppc64 syscall1	s390x,ppc64 # run on everything except s390x and ppc64 
> syscall2	!s390x,!ppc64,all # don't run on anything syscall3 # run on everything syscall4	all # 
> run on everything 32-bit syscall5	all:32 # run on everything non-64bit (basically same as 
> above) syscall6	!all:64,all
> 
> # not on s390x, everywhere on ppc64, others only 64bit bind		!s390x,ppc64,all:64 # not on 
> s390x, everywhere on ppc64, others only non-32bit bind		!s390x,ppc64,!all:32,all # everywhere 
> but 64bit x86_64 socketcall	!x86_64:64,all
> 
> The difference against my original proposal is that negation doesn't automatically include the 
> remainder from "all". IOW that !s390x doesn't add anything, only stops the expression 
> processing on s390x. This "kind of" works as logical AND, but not really. :)

This looks more understandable, and I like it more then the previous implicit
'all'.

Thanks for the explanation.

/M

> 
>> 
>> Best regards, /M
> 
> Jiri
> 

- -- 
Miroslav Vadkerti :: Senior Quality Assurance Engineer / RHCSS :: BaseOS QE - Security
Phone +420 532 294 129 :: CR cell +420 776 864 252 :: SR cell +421 904 135 440
IRC mvadkert at #qe #urt #brno #rpmdiff :: GnuPG ID 0x25881087 at pgp.mit.edu
Red Hat s.r.o, Purkyňova 99/71, 612 45, Brno, Czech Republic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT6I2EAAoJEBliWhMliBCH1BEH/RKT5AOFj0SJDD2o/yc3VeM4
QIp7VR36D5RRn27dgNB8/b7r6FW5NF8/ZC9H4+gdT4bNaw8ib6DkRJ9ez+HwaPmd
vr8Qa2syrzQISlm6vqJp8ahDNgYeJQugVRxAGe2pF/iSdP+d3gkrFydaahgHVZzg
LyprVcp5CHPNFEkOjV62Zb2RXy9HcZf0+2AuMyBWAf0+Lf/ooJa5nEfMhwGmkjcj
8FyHWVO+yTE999hEaK6s77A53NgvBAksKAloAy9ae1ObYG2A1Yo6Wqz4LN/XDqEL
K8qN7sAABOpGVw2AC1UeLcttfIfFjlfXepumEOR9zOwCmdq2CnF401PkoiQSwtU=
=+zUA
-----END PGP SIGNATURE-----