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

[Linda K. <lin...@hp...>]

On 8/11/2014 5: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.
> 
>>
>> 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 works better for me.

Thanks for all the examples.

-- ljk
> 
>>
>> Best regards,
>> /M
> 
> Jiri
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Audit-test-developer mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audit-test-developer
>