On 26/10/2020 19:39, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
>> On 26/10/2020 18:52, Eric Biggers wrote:
>>> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>>>> Replace the explicit EBOIV handling in the dm-crypt driver with calls
>>>> into the crypto API, which now possesses the capability to perform
>>>> this processing within the crypto subsystem.
>>>>
>>>> Signed-off-by: Gilad Ben-Yossef <gi...@benyossef.com>
>>>>
>>>> ---
>>>> drivers/md/Kconfig | 1 +
>>>> drivers/md/dm-crypt.c | 61 ++++++++++++++-----------------------------
>>>> 2 files changed, 20 insertions(+), 42 deletions(-)
>>>>
>>>> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
>>>> index 30ba3573626c..ca6e56a72281 100644
>>>> --- a/drivers/md/Kconfig
>>>> +++ b/drivers/md/Kconfig
>>>> @@ -273,6 +273,7 @@ config DM_CRYPT
>>>> select CRYPTO
>>>> select CRYPTO_CBC
>>>> select CRYPTO_ESSIV
>>>> + select CRYPTO_EBOIV
>>>> help
>>>> This device-mapper target allows you to create a device that
>>>> transparently encrypts the data on it. You'll need to activate
>>>
>>> Can CRYPTO_EBOIV please not be selected by default? If someone really wants
>>> Bitlocker compatibility support, they can select this option themselves.
>>
>> Please no! Until this move of IV to crypto API, we can rely on
>> support in dm-crypt (if it is not supported, it is just a very old kernel).
>> (Actually, this was the first thing I checked in this patchset - if it is
>> unconditionally enabled for compatibility once dmcrypt is selected.)
>>
>> People already use removable devices with BitLocker.
>> It was the whole point that it works out-of-the-box without enabling
>> anything.
>>
>> If you insist on this to be optional, please better keep this IV inside
>> dmcrypt.
>> (EBOIV has no other use than for disk encryption anyway.)
>>
>> Or maybe another option would be to introduce option under dm-crypt Kconfig
>> that
>> defaults to enabled (like support for foreign/legacy disk encryption
>> schemes) and that
>> selects these IVs/modes.
>> But requiring some random switch in crypto API will only confuse users.
>
> CONFIG_DM_CRYPT can either select every weird combination of algorithms anyone
> can ever be using, or it can select some defaults and require any other needed
> algorithms to be explicitly selected.
>
> In reality, dm-crypt has never even selected any particular block ciphers,
> even
> AES. Nor has it ever selected XTS. So it's actually always made users (or
> kernel distributors) explicitly select algorithms. Why the Bitlocker support
> suddenly different?
>
> I'd think a lot of dm-crypt users don't want to bloat their kernels with
> random
> legacy algorithms.
Yes, but IV is in reality not a cryptographic algorithm, it is kind-of a
configuration
"option" of sector encryption mode here.
We had all of disk-IV inside dmcrypt before - but once it is partially moved
into crypto API
(ESSIV, EBOIV for now), it becomes much more complicated for user to select
what he needs.
I think we have no way to check that IV is available from userspace - it
will report the same error as if block cipher is not available, not helping
user much
with the error.
But then I also think we should add abstract dm-crypt options here (Legacy
TrueCrypt modes,
Bitlocker modes) that will select these crypto API configuration switches.
Otherwise it will be only a complicated matrix of crypto API options...
Milan
