Elad Efrat wrote:
quoted text
> Garrett D'Amore wrote:
>
>   
>> 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.
>   

I hope there aren't any of those folks.  I.e., if you can provide
equivalent functionality (e.g. a template rc script that loads the
sysctls so that the system behaves the same for given securelevels),
then maybe we don't need to keep the old model around, at least not in
the kernel.

Keeping old models like this around doesn't come for free. 
Specifically, costs of doing so are:

    1) additional code size
    2) additional code paths that may or may not get test coverage
    3) additional complexity for users and support
    4) additional documentation impact (if X do Y, else do Z)

If at all possible, I'd vote to make a 100% switch.

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

Yes, it should be left to core@, but we can still make *suggestions*, right?

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

Okay.   But this applies to runtime as well.  I'd rather just cut the
cord and go forward, as long as you can reasonably emulate the old
behavior in startup scripts or something.

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

Anything under 10k is negligible.  Anything over 100k is cause for
concern.  There is a big gray area in the middle.  :-)  Basically, if it
makes life much harder for systems with constrained boot media, then it
is a problem.  10k should definitely be less than the threshold of pain,
but other than that, I'm not sure there is an easy answer.

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

Big NFS and CVS usage would probably be an excellent way to test
performance.  Maybe also do some kind of database runs, I'm not sure.

My gut is that the performance impact is likely not on the hottest code
paths.   But system call overhead (esp open()) should probably be
checked, because a lot of performance metrics seem to follow that result.

Core of course has the final word, but I suspect some small impact is
tolerable if it shown to be small on the mainstream archs (i386, sparc,
mips, powerpc).

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191