Darren J Moffat wrote: > 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. > I agree that Dan's changes are a good first step.
That next step: 1. Putting just the names of software providers in the kcf module and calling ddi_modopen/ddi_modclose to get the mechanisms. 2. Or doing [1] for all modules in /kernel/crypto and filtering out 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. > >
