On 11/17/2016 05:35 PM, Andrey Ryabinin wrote: > On 11/16/2016 11:47 PM, Ondrej Kozina wrote: >> (Please still consider it to be RFC only, I need to modify the uspace teststuite >> again due to changes in key_string format. Also the changes to dm-crypt documentation >> will follow before final submit. Feature wide I'd consider the patch being complete >> unless any bugs would emerge) >> >> The kernel key service is a generic way to store keys for the use of >> other subsystems. Currently there is no way to use kernel keys in dm-crypt. >> This patch aims to fix that. Instead of key userspace may pass a key >> description with preceding ':'. So message that constructs encryption >> mapping now looks like this: >> >> <cipher> [<key>|:<key_string>] <iv_offset> <dev_path> <start> [<#opt_params> <opt_params>] >> >> where <key_string> is in format: <key_size>:<key_type>:<key_description> >> >> Currently we only support two elementary key types: 'user' and 'logon'. >> Keys may be loaded in dm-crypt either via <key_string> or using >> classical method and pass the key in hex representation directly. >> > > I think we need to hexify key description too, because it can contain spaces. > <key_size> seems like unnecessary complication. Kernel knows key_size, it doesn't need > that information from userspace. Userspace (integration in cryptsetup) need to know key size. It reads DM table and parses information from it. So it is opposite direction - userspace need to get expected key size from kernel and if key in keyring with logon type, we cannot get key size from kernel. Kernel obviously have this information directly from keyring. > Handling different types is probably an overkill too. If it works with logon keys, > why would we need to use 'user' keys? Not sure if it is really needed but I do not think it is overkill, there will be more use cases than you original patch expected. Milan -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
