[dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

Hi List,

I recently upgraded one of my systems and after cryptsetup was updated,
included into my initramfs it fails to open the LUKS container.

In the very beginning I ended up with a 'Cannot initialize crypto backend'
error. After some debugging I managed to add the missing kernel modules to
get AF_ALGO. Now I am getting to a password prompt, enter my passphrase
and get a failure. I cannot recall the exact error msg, I remember though
it said something about a missing option.

Anyway, I traced the whole thing, and I think it's the following call that
creates the fatal error:
bind(<FD>,{sa_family=AF_ALG,SA_data=hash\0,88})=ENOENT)

First I had a failure on the socket() call, which I managed to get rid
off, now the actual bind() fails. I can see the problem is hash related,
but further assistance is appreciated.

Thanks in advance for your input

-Sven

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Milan Broz]

On 09/01/2014 09:32 PM, Sven Eschenberg wrote:
> I recently upgraded one of my systems and after cryptsetup was updated,
> included into my initramfs it fails to open the LUKS container.
> 
> In the very beginning I ended up with a 'Cannot initialize crypto backend'
> error. After some debugging I managed to add the missing kernel modules to
> get AF_ALGO. Now I am getting to a password prompt, enter my passphrase
> and get a failure. I cannot recall the exact error msg, I remember though
> it said something about a missing option.
> 
> Anyway, I traced the whole thing, and I think it's the following call that
> creates the fatal error:
> bind(<FD>,{sa_family=AF_ALG,SA_data=hash\0,88})=ENOENT)
> 
> First I had a failure on the socket() call, which I managed to get rid
> off, now the actual bind() fails. I can see the problem is hash related,
> but further assistance is appreciated.

Hi,

the dependence on AF_ALG (for LUKS) is optional and there is fallback
to old way. So in your described scenario it should still work.
(The ENOENT error above is not fatal error, it is indication that some function
is not available and code should simple use old way how to decrypt keyslot.)

Which exact version you are using? Be sure that you have the last 1.6.6
where I fixed some problems related to crypto API interface.

Can you post output with added --debug of command which fails?

If you are compiling cryptsetup yourself, which crypto backend are you using?
(If it is kernel API, then kernel must have required support, AF_ALG
API and all relevant crypto modules.)

Thanks,
Milan

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

On Mon, September 1, 2014 22:00, Milan Broz wrote:
> On 09/01/2014 09:32 PM, Sven Eschenberg wrote:
>> I recently upgraded one of my systems and after cryptsetup was updated,
>> included into my initramfs it fails to open the LUKS container.
>>
>> In the very beginning I ended up with a 'Cannot initialize crypto
>> backend'
>> error. After some debugging I managed to add the missing kernel modules
>> to
>> get AF_ALGO. Now I am getting to a password prompt, enter my passphrase
>> and get a failure. I cannot recall the exact error msg, I remember
>> though
>> it said something about a missing option.
>>
>> Anyway, I traced the whole thing, and I think it's the following call
>> that
>> creates the fatal error:
>> bind(<FD>,{sa_family=AF_ALG,SA_data=hash\0,88})=ENOENT)
>>
>> First I had a failure on the socket() call, which I managed to get rid
>> off, now the actual bind() fails. I can see the problem is hash related,
>> but further assistance is appreciated.
>
> Hi,
>
> the dependence on AF_ALG (for LUKS) is optional and there is fallback
> to old way. So in your described scenario it should still work.
> (The ENOENT error above is not fatal error, it is indication that some
> function
> is not available and code should simple use old way how to decrypt
> keyslot.)

I see, well, the trace does some close() after the failed bind(), munmap()
munlockall(), setpriority() and the exit_group() and I see an exited with
1 message, anyway, let'S check the other stuff ..

>
> Which exact version you are using? Be sure that you have the last 1.6.6
> where I fixed some problems related to crypto API interface.

Okay, I am using 1.6.4, will upgrade it and check again...

>
> Can you post output with added --debug of command which fails?
>
> If you are compiling cryptsetup yourself, which crypto backend are you
> using?
> (If it is kernel API, then kernel must have required support, AF_ALG
> API and all relevant crypto modules.)

Always used the kernel backend. I reused the kernel config (just minor
upgrade) which worked with the old cryptsetup.

>
> Thanks,
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Milan Broz]

On 09/01/2014 10:12 PM, Sven Eschenberg wrote:
> On Mon, September 1, 2014 22:00, Milan Broz wrote:
>> Which exact version you are using? Be sure that you have the last 1.6.6
>> where I fixed some problems related to crypto API interface.
> 
> Okay, I am using 1.6.4, will upgrade it and check again...

ok, then it is different issue I thought (there was a change
in 1.6.5 which caused a lot of similar issues), see below.

Anyway, please try 1.6.6. as well - there was some related changes.

>> Can you post output with added --debug of command which fails?
>>
>> If you are compiling cryptsetup yourself, which crypto backend are you
>> using?
>> (If it is kernel API, then kernel must have required support, AF_ALG
>> API and all relevant crypto modules.)
> 
> Always used the kernel backend. I reused the kernel config (just minor
> upgrade) which worked with the old cryptsetup.

So if you use kernel backend you simply must have kernel with the AF_ALG interface.

Also be sure you have SHA1 and hash used in your LUKS (if differs from SHA1).
(SHA1 is mandatory for LUKS support, crypto backend also uses it to check
that API is working -  I did not find other reliable way...)

Anyway, I would say that it is not problem in cryptsetup but that some required
kernel module is missing (it can be some dependence like cipher mode helper
or cryptomgr...)

Milan

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

On Mon, September 1, 2014 22:41, Milan Broz wrote:
> On 09/01/2014 10:12 PM, Sven Eschenberg wrote:
>> On Mon, September 1, 2014 22:00, Milan Broz wrote:
>>> Which exact version you are using? Be sure that you have the last 1.6.6
>>> where I fixed some problems related to crypto API interface.
>>
>> Okay, I am using 1.6.4, will upgrade it and check again...
>
> ok, then it is different issue I thought (there was a change
> in 1.6.5 which caused a lot of similar issues), see below.
>
> Anyway, please try 1.6.6. as well - there was some related changes.
>

No difference with 1.6.6.

>>> Can you post output with added --debug of command which fails?
>>>
>>> If you are compiling cryptsetup yourself, which crypto backend are you
>>> using?
>>> (If it is kernel API, then kernel must have required support, AF_ALG
>>> API and all relevant crypto modules.)
>>
>> Always used the kernel backend. I reused the kernel config (just minor
>> upgrade) which worked with the old cryptsetup.
>
> So if you use kernel backend you simply must have kernel with the AF_ALG
> interface.
>
> Also be sure you have SHA1 and hash used in your LUKS (if differs from
> SHA1).
> (SHA1 is mandatory for LUKS support, crypto backend also uses it to check
> that API is working -  I did not find other reliable way...)
>
> Anyway, I would say that it is not problem in cryptsetup but that some
> required
> kernel module is missing (it can be some dependence like cipher mode
> helper
> or cryptomgr...)

Is there any sophisticated way to find out, what could be missing? Except
trial and error maybe ;-)?

Here's the CRYPTO config of the kernel that works with old cryptsetup:

CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_XTS=y
CONFIG_CRYPTO_RMD160=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
-----
What I added to get to the passphrase for current cryptsetup is:
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API=y <= AF_ALGO
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
----

The Volume is AES-XTS-plain and the hashspec sha1

I can't see what might be missing ...

>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Milan Broz]

On 09/01/2014 11:35 PM, Sven Eschenberg wrote:
> Here's the CRYPTO config of the kernel that works with old cryptsetup:
> 
> CONFIG_CRYPTO=y
> CONFIG_CRYPTO_ALGAPI=y
> CONFIG_CRYPTO_ALGAPI2=y
> CONFIG_CRYPTO_AEAD2=y
> CONFIG_CRYPTO_BLKCIPHER=y
> CONFIG_CRYPTO_BLKCIPHER2=y
> CONFIG_CRYPTO_HASH=y
> CONFIG_CRYPTO_HASH2=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_PCOMP2=y
> CONFIG_CRYPTO_MANAGER=y
> CONFIG_CRYPTO_MANAGER2=y
> CONFIG_CRYPTO_GF128MUL=y
> CONFIG_CRYPTO_WORKQUEUE=y
> CONFIG_CRYPTO_CBC=y
> CONFIG_CRYPTO_XTS=y
> CONFIG_CRYPTO_RMD160=y
> CONFIG_CRYPTO_SHA1=y
> CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_586=y
> -----
> What I added to get to the passphrase for current cryptsetup is:
> CONFIG_CRYPTO_ANSI_CPRNG=y
> CONFIG_CRYPTO_USER_API=y <= AF_ALGO
> CONFIG_CRYPTO_USER_API_HASH=y
> CONFIG_CRYPTO_USER_API_SKCIPHER=y
> ----
> 
> The Volume is AES-XTS-plain and the hashspec sha1
> 
> I can't see what might be missing ...

If you can send which exact kernel version it is and full .config,
which fails I can try to reproduce it.

Thanks,
Milan

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

Hi Milan,


On Wed, September 3, 2014 18:56, Milan Broz wrote:
> On 09/01/2014 11:35 PM, Sven Eschenberg wrote:
>> Here's the CRYPTO config of the kernel that works with old cryptsetup:
>>
>> CONFIG_CRYPTO=y
>> CONFIG_CRYPTO_ALGAPI=y
>> CONFIG_CRYPTO_ALGAPI2=y
>> CONFIG_CRYPTO_AEAD2=y
>> CONFIG_CRYPTO_BLKCIPHER=y
>> CONFIG_CRYPTO_BLKCIPHER2=y
>> CONFIG_CRYPTO_HASH=y
>> CONFIG_CRYPTO_HASH2=y
>> CONFIG_CRYPTO_RNG2=y
>> CONFIG_CRYPTO_PCOMP2=y
>> CONFIG_CRYPTO_MANAGER=y
>> CONFIG_CRYPTO_MANAGER2=y
>> CONFIG_CRYPTO_GF128MUL=y
>> CONFIG_CRYPTO_WORKQUEUE=y
>> CONFIG_CRYPTO_CBC=y
>> CONFIG_CRYPTO_XTS=y
>> CONFIG_CRYPTO_RMD160=y
>> CONFIG_CRYPTO_SHA1=y
>> CONFIG_CRYPTO_SHA256=y
>> CONFIG_CRYPTO_AES=y
>> CONFIG_CRYPTO_AES_586=y
>> -----
>> What I added to get to the passphrase for current cryptsetup is:
>> CONFIG_CRYPTO_ANSI_CPRNG=y
>> CONFIG_CRYPTO_USER_API=y <= AF_ALGO
>> CONFIG_CRYPTO_USER_API_HASH=y
>> CONFIG_CRYPTO_USER_API_SKCIPHER=y
>> ----
>>
>> The Volume is AES-XTS-plain and the hashspec sha1
>>
>> I can't see what might be missing ...
>
> If you can send which exact kernel version it is and full .config,
> which fails I can try to reproduce it.

Will mail that in a bit directly to you. I looked at the strace again and
realized the following:
the call to initialize the backend with the fixed values in sockaddr_alg
(AF_ALG,"hash","sha1") obviously succeeds, the one after entering the
passphrase, which is filled with AF_ALG, "hash", and the hashname, which
should be sha1 again, seems to fail.

Unfortunately strace only displays the initial part os sa_data, so I can
see sa_type is hash, but I cannot see what is actually passed in sa_name.
But as the volume uses sha1, I'd expect that the bind() call has the exact
same values in sockaddr_alg as the one that is used to test+initialize the
kernel crypto backend. This is a little surprising to me.

Do you know how I could force strace to show the complete sa_data field in
the bind() call? -s to increase the string size has no effect,
unfortunately.

>
> Thanks,
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Milan Broz]

On 09/03/2014 11:03 PM, Sven Eschenberg wrote:
> Will mail that in a bit directly to you. I looked at the strace again and
> realized the following:
> the call to initialize the backend with the fixed values in sockaddr_alg
> (AF_ALG,"hash","sha1") obviously succeeds, the one after entering the
> passphrase, which is filled with AF_ALG, "hash", and the hashname, which
> should be sha1 again, seems to fail.

I tried your config (just added hw drivers so it boots on my VM)
and for my non-initram i386 system it works.

The only module it requires to load (all other are compiled in) is hmac,
so try CONFIG_CRYPTO_HMAC=y or check it is in initramfs.

And obviously, removing this module so kernel cannot find it causes
...
socket(PF_ALG, SOCK_SEQPACKET, 0)       = 6
bind(6, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = -1 ENOENT (No such file or directory)
                                = 0
I will probably try to add some better debug messages here
(but you did not send me --debug output anyway :-)

Milan

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

Hi Milan,

still looking at an strace output flood (PDBKF2 I guess), but it looks
like the change from modular to builtin for HMAC did the trick. Thank you
so much for your effort.

For me two major questions remain though:
1.) Why did an older version of cryptsetup work without these modules?
2.) Why is HMAC needed? It is not obvious and if some other kernel module
needs it, why is the dependecy missing?
4.) if HMAC dependecy is owed to cryptsetup specificly, is that documented
already?

With best Regards

A delighted and happy user

-Sven

On Thu, September 4, 2014 09:24, Milan Broz wrote:
> On 09/03/2014 11:03 PM, Sven Eschenberg wrote:
>> Will mail that in a bit directly to you. I looked at the strace again
>> and
>> realized the following:
>> the call to initialize the backend with the fixed values in sockaddr_alg
>> (AF_ALG,"hash","sha1") obviously succeeds, the one after entering the
>> passphrase, which is filled with AF_ALG, "hash", and the hashname, which
>> should be sha1 again, seems to fail.
>
> I tried your config (just added hw drivers so it boots on my VM)
> and for my non-initram i386 system it works.
>
> The only module it requires to load (all other are compiled in) is hmac,
> so try CONFIG_CRYPTO_HMAC=y or check it is in initramfs.
>
> And obviously, removing this module so kernel cannot find it causes
> ...
> socket(PF_ALG, SOCK_SEQPACKET, 0)       = 6
> bind(6, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = -1
> ENOENT (No such file or directory)
>                                 = 0
> I will probably try to add some better debug messages here
> (but you did not send me --debug output anyway :-)
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Milan Broz]

On 09/05/2014 12:54 AM, Sven Eschenberg wrote:
> For me two major questions remain though:
> 1.) Why did an older version of cryptsetup work without these modules?

Hi,

HMAC is mandatory, so check your previous config... I guess just some magic
switched it to module... :)

> 2.) Why is HMAC needed? It is not obvious and if some other kernel module
> needs it, why is the dependecy missing?

It is not dependence for kernel module but requirement of PBKDF2 used in LUKS.

But as I said, it should report problems in more clear error messages...

> 4.) if HMAC dependecy is owed to cryptsetup specificly, is that documented
> already?

I do not think there is a list of required kernel modules. Perhaps it should
be added somewhere. But I am afraid exact list will depend on kernel versions and
other configuration (crypto mgr, fips, hw accel. support, ...)

In short, for kernel backend, AF_ALG must be supported in general.

Then for LUKS: generic hash support, specific hash used in LUKS and HMAC is required.
With 1.6.5 and later it will optionally utilize also skcipher interface (so you need
the block cipher and block mode used in LUKS header.

For TrueCrypt support you need the same, (hash, hmac, block cipher, block mode).

Perhaps man page or FAQ could be more descriptive here (... send a patch ;-)

Thanks,
Milan

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Arno Wagner]

On Fri, Sep 05, 2014 at 17:29:26 CEST, Milan Broz wrote:
[...] 
> I do not think there is a list of required kernel modules. Perhaps it
> should be added somewhere.  But I am afraid exact list will depend on
> kernel versions and other configuration (crypto mgr, fips, hw accel. 
> support, ...)
> 
> In short, for kernel backend, AF_ALG must be supported in general.
> 
> Then for LUKS: generic hash support, specific hash used in LUKS and HMAC
> is required.  With 1.6.5 and later it will optionally utilize also
> skcipher interface (so you need the block cipher and block mode used in
> LUKS header.
> 
> For TrueCrypt support you need the same, (hash, hmac, block cipher, block
> mode).
> 
> Perhaps man page or FAQ could be more descriptive here (... send a patch
> ;-)

It think eventually we will need some kind of trouble-shooting
FAQ or manual, but at this time it seems the incidents where that
problem manifests are rare enough that we can deal on the list 
with it. I have been thinking for a while about splitting up
the FAQ though, but at the moment I simply do not have the time 
to it right. Maybe later this year.

Gr"usse,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] cryptsetup upgrade to 1.6.x unlocking problem in initramfs

[Sven Eschenberg]

On Fri, September 5, 2014 17:29, Milan Broz wrote:
> On 09/05/2014 12:54 AM, Sven Eschenberg wrote:
>> For me two major questions remain though:
>> 1.) Why did an older version of cryptsetup work without these modules?
>
> Hi,
>
> HMAC is mandatory, so check your previous config... I guess just some
> magic
> switched it to module... :)
>

No, actually it was modular. In fact it was my fault, the older kernel's
initramfs included /lib/modules completely, from what I gathered by
checking it's initramfs. I guess the issue was nagging me back then
already and I took the easy path ;-).

>> 2.) Why is HMAC needed? It is not obvious and if some other kernel
>> module
>> needs it, why is the dependecy missing?
>
> It is not dependence for kernel module but requirement of PBKDF2 used in
> LUKS.
>
> But as I said, it should report problems in more clear error messages...
>
>> 4.) if HMAC dependecy is owed to cryptsetup specificly, is that
>> documented
>> already?
>
> I do not think there is a list of required kernel modules. Perhaps it
> should
> be added somewhere. But I am afraid exact list will depend on kernel
> versions and
> other configuration (crypto mgr, fips, hw accel. support, ...)

That is true, of course. A list of modules necessary for kernel backend
and one for the default parameters might not be the worst idea, I think.
What do others say?

>
> In short, for kernel backend, AF_ALG must be supported in general.
>
> Then for LUKS: generic hash support, specific hash used in LUKS and HMAC
> is required.
> With 1.6.5 and later it will optionally utilize also skcipher interface
> (so you need
> the block cipher and block mode used in LUKS header.
>
> For TrueCrypt support you need the same, (hash, hmac, block cipher, block
> mode).
>
> Perhaps man page or FAQ could be more descriptive here (... send a patch
> ;-)

Arno already stated that the FAQ is becoming quite large, I am not sure
where we should add it.

>
> Thanks,
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Regards

-Sven