Anthony Scarpino wrote:
> Garrett D'Amore wrote:
>
> The crypto module is loaded to be used, but the shutdown process has
> gone too far as svc://system/cryptosvc (aka kcfd) has been shutdown..
> The modules now tries to register with the framework, but the
> framework cannot verify the signature on the module (via kcfd), so
> registration fails and the error message is sent.. The failure to
> register doesn't mean the module can't be used, as it can be access
> directly. Knowing that the system is shutting down prevents us from
> emitting the error message that is not necessary and causing
> confusion. This is pretty much the only time this error message is not
> useful.
So, what is needed is for the crypto framework itself to recognize that
this has happened... that kcfd has terminated due to a system shutdown.
So instead of a module saying "failed to register..." the framework,
prior to returning that failure code, should message it on behalf of the
module. And the framework can have this check for it.
I do want to point out one really key thing -- reliance on sys_shutdown
is probably not perfect. The variable is set via a uadmin() system
call, kcfd might be shutdown via SMF before this point. By the time
uadmin() is called, it might be a bit late. (Depends on whether kcf
dies via SMF or via uadmin()'s internal "killall".)
Actually, in retrospect, using a userland daemon to handle this is IMO
the wrong approach. Reading the code, it looks like the kcfd code was
intended to keep crypto resources in kernel space associated with a
single process for accounting, etc. But, it turns that ZFS has much the
same problem, and they've taken a different approach -- theres a new
scheduling class just for this purpose.
I recommend that the crypto team look to see if they can use a similar
approach... ultimately, eliminating the userland component and replacing
it with a kernel component would be more robust here.
- Garrett
