On Monday, June 08, 2015 at 06:52:00 AM, Herbert Xu wrote: > On Fri, Jun 05, 2015 at 04:38:03PM +0200, Marek Vasut wrote: > > In general, it would probably make sense to add a flag to .setkey() to > > store the key in a keyslot. The keyslot allocation would be up to the > > driver. In case all keyslots would be full, the setkey() with the flag > > set would simply fail. This would imply you would need to have a > > counterpart function to .setkey() to free keyslots -- something like > > .unsetkey() . > > Changing setkey is going to cause too much churn. In any case > I don't think these key slots should be written to by the kernel > since the intention appears to be for entites outside the kernel > to place secret keys in there that can then be used but not read > by the kernel. You mean like bootloader or you mean userspace code ? Maybe Jay can explain how these slots are intended to be used. I'd like to know the expected usecase. > So as far as the kernel is concerned these are constant keys. > > Therefore there should be no need for unsetkey. > > So perhaps just add a new call setkey_slot that is optional and > only needs to be implemented by drivers such as ccp. Might work as well ... but let's maybe wait for the usecase. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
