On Fri, 24 Mar 2006 23:24:47 +0200
Elad Efrat <elad@NetBSD.org> wrote:

quoted text
> As for performance, same list applies. There is a potential for slower
> performance due to the way kauth(9) works: it dispatches authorization
> requests to a list of listeners, making the amount of listeners directly
> affect the performance of an authorization request.
> 
> My machines at home running kauth(9) have seen no performance impact at
> all, but more testing on various architectures should be done to get
> some "official" numbers...

Was this profiled?  Of course, performance impact on the system as a
whole may become worse as more restrictions are applied to more types of
accesses as well, IMO. I.E. if more frequent code paths eventually also
need to verify for authorization (is this part of future goals?  What
are worst expected future scenarios?)

I would be interested in seeing common cases before/after profiled data,
considering the assumed overhead of a list of function pointers being
ran for a particular scope, with a function call per listener (if I
properly understood kauth(9))...  Especially if we intend to totally
replace the old system by it.  If I recall we do have architectures with
a high function call cost...  Will such an architecture, possibly a
candidate for securelevel restrictions in an embedded device, suffer
from this?  Or are the costs minimal?

Nonetheless, I do recognize the high flexibility of this system compared
to doing a check against a single global securelevel variable, of
course.  It will allow to integrate a number of nice features.  :)
So far, from the man page, I like the design, but it also made me wonder
about the performance impact, especially as more specific restrictions
get added, a number of LKMs loaded as the kernel becomes more
dynamic/modular, etc

If profiled data and future expectations do show a significant
performance impact, it would probably be a good idea to continue
supporting the less flexible old method instead of obsoleting it
totally, or to review the implementation details of kauth(9). 

Also, could all authorization checks still be disabled as a whole, just
like when we set the kernel to insecure?  Or would this code always be
within the path of common syscalls (although possibly without
listeners)?  If it can totally be disabled, I assume that LKMs could
register new listeners, but that they simply would never be called?

Are there reasons why simply setting a deny flag per scope per security
property wouldn't work, instead of calling a list of functions which can
dynamically defer or deny?  If so, which possible scenario demonstrates
that such live flexibility is required?

Just so we work out or eliminate the performance concerns.  I admit I
didn't look at the code yet have to ask so many questions...

Thanks,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.