On 11/17/2016 09:06 PM, Ondrej Kozina wrote:
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.
I see. You're right the kernel key description may really contain
whitespace chars, bummer. Well what I'm thinking atm is rejecting any
keys with descriptions containing whitespaces. But let me ask Mike or
Alasdair what do they think about it.
Answering myself:
so I looked at it once again in detail and I'm now convinced we actually
don't have to do anything about it (provided we'd agree on rejecting any
key_description containing whitespace):
every table is first processed by dm_split_args() before it's passed to
any target driver for further processing. That's true also for message
ioctls. In case you pass table (or message) with whitespace in
key_description it'll fail to construct such dm-crypt target because
number of arguments passed will not match the dm-crypt template.
key_string in format: ':32:logon:some:user key' is considered to be 2
arguments and not single one due to the whitespace.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
