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
| ||
|
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
Powered by blists - more mailing lists