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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <874k04e6o4.ffs@tglx>
Date:   Wed, 29 Jun 2022 00:59:07 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alexandre Messier <alex@...ssier.org>,
        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+

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.

Thanks,

        tglx