Thanks for taking the time to reply

On Sat, 25 Mar 2006 23:28:28 +0200
Elad Efrat <elad@NetBSD.org> wrote:

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

I somehow thought that the interface allowed LKMs to plug-in "listener"
callback hooks, this might have been a wrong assumption.

quoted text
> > 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.

I hope that it isn't news that NetBSD is also used on embedded systems
which generally require the securelevels functionality...  Such embedded
systems can often consist of a low-end ARM based board for instance.
Possibly a motivation for it's users to worry more about performance and
kernel stack and code size.  It wasn't voluntary on my part to repeat
what others said, but we probably shared a common concern :)

I understand that the traditional behavior of securelevels can be
observed with a new implementation under the new framework, but probably
at a cost (this cost could be very moderate, we however have to find
out).

quoted text
> 
> > 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".

My vision of the interface includes the scope-specific callback
functions iterator (which I indeed included in "implementation").  Then
of course there are the listeners themselves which can implement the
decisions based on wanted factors, if I understand (probably what you
mean by implementation).  I will reformulate the previous question below
the next quote:

quoted text
> > Or would this code always be
> > within the path of common syscalls (although possibly without
> > listeners)? 
> 
> Why would there be "no listeners"?

So the question above should have been: Does a kernel configured as
"insecure" avoid even entering the kauth(9) framework, or do they simply
find an empty listeners list?  In other words, does the new interface
affect the performance of insecure kernels as well.

quoted text
> > 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.

I do not understand how using flags, avoiding to iterate over a number
of callback functions, calling each of them, can be called a
pseudo-performance improvement :)  However, as I now read the rest of
the thread (which I should have done before replying), it answered this
question (functions are much more powerful and will allow fancy features
like delegation to a daemon and/or remote centralized server).

quoted text
> > 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.

I unfortunately won't be able to test the code very soon but reading it
is on my TODO.  If I have any more questions at least they'll be
informed ones then :)

Thanks again,
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.