lkml.org 
[lkml]   [2022]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [REGRESSION] Unable to unlock encrypted disk starting with kernel 5.19-rc1+
From
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

\
 
 \ /
  Last update: 2022-06-29 01:25    [W:0.228 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site