linux-kernel - Re: [REGRESSION] Unable to unlock encrypted disk starting with kernel 5.19-rc1+

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a63bba3a-583b-603a-0a4b-2b329b6af1e6@me.ssier.org>
Date:   Tue, 28 Jun 2022 19:24:22 -0400
From:   Alexandre Messier <alex@...ssier.org>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, Andrew.Cooper3@...rix.com,
        mingo@...hat.com, dave.hansen@...ux.intel.com, x86@...nel.org,
        regressions@...ts.linux.dev
Subject: Re: [REGRESSION] Unable to unlock encrypted disk starting with kernel
 5.19-rc1+

On 2022-06-28 18:59, Thomas Gleixner wrote:
> Alexandre,
> 
> On Tue, Jun 28 2022 at 17:31, Alexandre Messier wrote:
>> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
>>                   pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
>>                   fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl
>>                   nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq
>>                   monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave
>>                   avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm
>>                   sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce
>>                   topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb
>>                   cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall
>>                   fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed
>>                   adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1
>>                   xsaves cqm_llc cqm_occup_llc cqm_mbm_total
>>                   cqm_mbm_local
> 
> So this CPU supports XSAVEC and XSAVES which means the kernel uses
> XSAVES as the kernel before that.
> 
>> And here is the dmesg output of 5.19-rc4 without the revert (taken from the
>> initramfs). I put it on a paste service since it is too big for email:
>>
>>   https://paste.debian.net/1245491/
> 
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
> [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [    0.000000] x86/fpu: xstate_offset[9]:  832, xstate_sizes[9]:    8
> [    0.000000] x86/fpu: Enabled xstate features 0x207, context size is 840 bytes, using 'compacted' format.
> 
> This is correct. Is there any difference on a 5.18 kernel or on 5.19-rc
> with the commit reverted? I doubt that.
> 
> I'm completely puzzled and stared at the commit in question on and off,
> but I can't spot the fail.
> 
>> I setup an unencrypted Debian installation on another drive to be able to run
>> cryptsetup commands in userspace while using rc4, and was able to see the
>> issue. In a up-to-date Debian Sid installation (important, more on this below),
>> running these commands makes it possible to reproduce the issue:
>>
>>   dd if=/dev/zero bs=1M count=20 of=./test.img
>>   sudo cryptsetup luksFormat ./test.img
>>   sudo cryptsetup luksOpen ./test.img test_crypt
>>
>> The "luksOpen" will fail with the same error message I get on my main system.
>>
>> It seems using the latest Debian Sid is important. At first, I was trying with
>> Debian Bullseye, but everything was working, even unlocking my main drive.
>>
>> Could it be a difference due to the cryptsetup version? Sid is using 2.4.3,
>> while Bullseye is based on 2.3.7. I will try to compile cryptsetup 2.4.3 and
>> use it in a Bullseye system with kernel 5.19-rc4, to see if the issue occurs
>> in that setup.
> 
> It might use a different crypto algorithm.
> 
> Still confused....
> 
> I'll have another look tomorrow morning with brain awake.

Thomas, Borislav,

Well this is embarrassing... I ran the test Dave sent in his email, and when
running it on that unencrypted Debian Sid installation with kernel 5.19-rc4, it
failed too, but indicated that "aes-xts" was not available... It was right. 

I forgot to mention I am using a custom kernel config, and indeed CRYPTO_XTS
was not enabled. When I enabled it, the cryptsetup benchmark worked, along with
the test that previously failed with the test file.

So I enabled that option too on my main installation and I am now able to
unlock the drive like before. I don't know why it is needed now, but that fixed
the issue.

Sorry again for the trouble, this was not a kernel regression, but my error.

Thanks,
Alex

#regzbot invalid: Missing kernel config, not kernel regression

> 
> Thanks,
> 
>         tglx