Matthew Mondor wrote:

> 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?)

No, it wasn't profiled yet. There are no "more restrictions" planned
for now.

> If I recall we do have architectures with
> a high function call cost...

AFAIK, this is not a consideration. There's no easy way to say it, but
I am simply not working on this with a 486 in mind. Nor with a Vax in
mind, or whatever the architecture(s) you are referring to are...

However.. I *am* trying to make the new code fast as possible. (note:
you are referring *VERY* new code; there have been no efforts to further
optimize it)

I'd like to take this opportunity to state, again, that overhead is to
be expected because we're introducing here a new subsystem (both for
the securelevel-specific cases *and* wherever we're using kauth(9) where
we previously didn't) that does more things. The benefit is rather
obvious, and if the performance of this code on archaic machines is a
consideration that can prevent the integration of kauth(9) in NetBSD,
then there is no point to continue working on any of it.

> 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

The performance impact entirely depends on how many listeners each
scope has, and what each of them is doing in order to make an
authorization decision.

Also, why would "a number of LKMs loaded" affect the performance of
kauth(9)?

> If profiled data and future expectations do show a significant
> performance impact, [...]

Why do everyone keep repeating this? do you have hardware you're
interested in the performance of kauth(9) on? get the code from CVS and
just run it, then post back. I do not have unlimited resources (time
nor hardware) to test this code in all possible environments.

> Also, could all authorization checks still be disabled as a whole, just
> like when we set the kernel to insecure? 

Yes. You too, are confusing "implementation" with "interface".

> Or would this code always be
> within the path of common syscalls (although possibly without
> listeners)? 

Why would there be "no listeners"?

> If it can totally be disabled, I assume that LKMs could
> register new listeners, but that they simply would never be called?

This is simply not how it works. You do not take a step forward to just
take two steps back.

> 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?

Yes. Please, no pseudo-performance improvement suggestions that over
complicate the system, diverge from a known, tested, design, without
introducing the need for them first.

> Just so we work out or eliminate the performance concerns.

The best way you can eliminate (or confirm) your performance concerns
are by testing the code yourself in your own environment.

-e.

-- 
Elad Efrat