What you wrote suggested that the performance of kauth(9) may be
affected merely by loading LKMs. Of course that if an LKM adds more
listeners to a scope, there will be a performance hit.
But how many LKMs do you know that do that? :) also, someone who
is loading an LKM is knowingly accepting the performance hit (which,
btw, depends on the LKM, and not kauth(9) itself) and it is up to
the LKM author to take care of that.
If we, again, look at the concerns, there is the code size issue and the
performance issue.
For the first, I already showed that it is very likely that the change
will be around 10kb of change in the resulting kernel image; probably
less. Given that NetBSD's kernel size keeps growing every year, I see
no reason why this should even be a consideration in this case.
As to performance, again, people who suspect a performance hit with the
new code on their embedded/ancient/whatever hardware can just go ahead
and test it. On my machines I haven't seen any performance hit, but then
again maybe the users running i386/amd64 are not so common in the NetBSD
world.
I'd like to ask everyone that before they continue with their chaotic
prophecies they first take the time to do the actual tests.
You keep confusing yourself, and potentially others.
The interface to determine whether a kernel is "insecure" or not is
by "entering" the kauth(9) framework. That is how it works.
People apparently keep replying to messages on this thread without
reading my initial proposal, that addressed the vast majority of
questions that popped up during the discussion.
The NetBSD kernel will no longer check for a single variable, or
multiple variables, to know what state the kernel is in. This is
*exactly* what I want to change. Before proceeding with an operation
that can potentially change the TCB, the request would be dispatched
to kauth(9) for a decision. This is the change in interface.
Obviously, as I repeat again and again, there will be a performance hit
because of the change in interface. But let's examine these performance
concerns a little bit closer, shall we?
This thread is about the integration of securelevel and kauth(9), not
kauth(9) itself, as kauth(9) itself is planned ot be merged.
Now, did you take a look at the operations that require a securelevel
decision before you made any of your comments? these include things
like loading an LKM, or changing packet filter rules, or changing some
superuser-only file flags, etc. (the list is available online)
Can you honestly suggest that the performance impact -- and by that I
mean, the tiny performance impact, as by default we're not really doing
anything more than call a function with a switch statement -- will be
noticed, for said operations?
Your system loads LKMs during startup. Will the above have impact of
more than a fraction of a second on any architecture? if it does, will
it affect *normal* operation? and what about packet filter rules? when
do you load those?
For the changes proposed in this thread, folks, and let me say it as
clear as possible, performance is simply not a concern.
This is essentially commenting on code that does not yet exist. By
default, there is only one callback on each scope. Attaching new
callbacks is done by LKMs, which are loaded by the admin. You can only
assume that if you add functionality (by loading LKMs) you can expect
more overhead.
Until there is actual code, the assumption should be that here, too,
there is only one callback.
Because what you describe as a performance improvement on paper, is,
in practice, breaking the design of the kauth(9) subsystem for little
to no reason. And, as I said, for the topic of this thread, performance
is not a concern.
-e.
--
Elad Efrat
