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]

Date:   Tue, 28 Jun 2022 17:31:09 -0400
From:   Alexandre Messier <alex@...ssier.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, tglx@...utronix.de,
        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 05:20, Borislav Petkov wrote:
> On Tue, Jun 28, 2022 at 01:13:30AM -0400, Alexandre Messier wrote:
>> Please let me know if more information is needed, or if some tests are needed
>> to be run.
> 
> Yeah, pls send /proc/cpuinfo and full dmesg - privately is fine too.

Here is the cpuinfo output:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 25
model		: 80
model name	: AMD Ryzen 7 5700G with Radeon Graphics
stepping	: 0
microcode	: 0xa50000c
cpu MHz		: 3514.072
cache size	: 512 KB
physical id	: 0
siblings	: 16
core id		: 0
cpu cores	: 8
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 16
wp		: yes
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
                  clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv
                  svm_lock nrip_save tsc_scale vmcb_clean flushbyasid
                  decodeassists pausefilter pfthreshold avic v_vmsave_vmload
                  vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid
                  overflow_recov succor smca fsrm
bugs		: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips	: 7585.33
TLB size	: 2560 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

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/

> 
> Also, it would be lovely if I were able to reproduce this on a machine
> here but mine doesn't have a crypto rootfs.
> 
> Perhaps you can point me to the exact instructions you're running to
> decrypt your rootfs and I can try to create a usb crypto disk and try to
> reproduce it with them...

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.

Thanks,
Alex
 
> 
> Thx.
>