Anthony Scarpino wrote: > Concern: > > I'm a bit confused here please tell me if I am wrong in my understanding > of the code... Previously the modules and supported mechanism list was > in kcf.conf. Now I see the config in the kernel. If we add a new > module or mechanism to an existing module, we need to update kcf > kcf_soft_config_init)? Or is there a chicken and egg problem that I > don't see, and after everything is loaded the support list will be > coming from the module? My initial reaction is we've shift the > configuration burden from userland to kernel instead of eliminating most > of the burden..
The burden has moved to updating kcf but when we add new modes we update kcf anyway because that is where the modes code is (Nylon). The reason for moving all this config out of kcf.conf is so that we don't have to edit kcf.conf via class action scripts or SMF services or bfu on upgrade because is it very painful to do so and will get even more painful when we switch to IPS. It also has the very anoying property to causing a very hard to debug problem, cryptoadm shows that a kernel software provider provides a mechanism, eg AES_CCM, but kcf.conf doesn't have it listed so it doesn't work. That could still happen if someone adds a mode and forgets to update kcf_soft_config_init. Ideally we wouldn't have to hard code any of this and software providers could act just like hardware ones and supply kcf with the list that they support. I see this fix as an interim step towards that since I believe we need a bigger project to address the distinctions between software and hardware providers going forward. Particularly given that in the future many of our providers may actually be "hybrid" and the software/hardware distinction isn't actually that interesting. There is also the problem of only allowing a mechanism from a single software provider at the moment a restriction we don't have on hardware providers. None of the userland changes that Dan has done would be wasted by a future change in how we deal with providers and in fact this is really the most important part of the change. -- Darren J Moffat
