Garrett D'Amore wrote:

> Offer both of these solutions, and everyone should be happy. :-) 

Yes, both "a" and "b" are planned to be done; sorry if it wasn't
implied... :)

> Even
> better, item "a" should generate a warning message if possible.  (Maybe
> if we ever get a true kernel loader, it could look for references to
> securelevel and issue a warning.  Until we have a real kernel loader,
> this might not be realistic.  :-)
> 
> We can announce eventual removal of securelevel as a variable at all,
> but I think it makes sense to have a full release cycle in the middle to
> allow folks with 3rd party code to adapt.

Even though we can provide the wrapping to transparently hide the fact
that there are multiple knobs from users who don't care about it, I can
only assume some people will simply want to retain the traditional
behavior.

Either way, both of these decisions (generating a warning, removing the
kern.securelevel variable entirely) are ones that someone else will have
to make.

> Btw, I would prefer not to have kauth be conditionally defined. 

If kauth(9) will ever be integrated in NetBSD, it is not going to be
conditionally defined. The __HAVE_KERNELAUTH conditional was to
illustrate how a module that wants to support multiple versions of
NetBSD might be written in relevant parts.

> One question
> that should probably be answered first would be to compare the size of a
> kernel with kauth and without on some "size sensitive" machines: i386,
> vax, and mips.  If the difference is minimal, then there is no point in
> having a conditional, IMO.

Since you brought it up, there are two considerations we need to take
into account regarding kauth(9), the first being size (as you mentioned)
and the second being performance.

I have never compared the sizes of pre-kauth(9) and post-kauth(9)
kernels, but the changes that might affect the size are as follows:

  - Introduction of new code, the kauth(9) subsystem;
  - Removal of old code, mostly functions from kern/kern_prot.c;
  - Changing suser() calls to kauth_authorize_generic() calls;
  - Changing struct ucred/struct pcred accesses to kauth_cred_*()
    calls.

What would be a size difference that might make you worry? :)

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

-e.

-- 
Elad Efrat