linux-kernel - Re: [LKP] Re: [x86/mm/64] f154f29085: BUG:kernel_reboot-without-warning_in_boot

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:   Thu, 16 Dec 2021 15:04:16 +0800
From:   Yin Fengwei <fengwei.yin@...el.com>
To:     Borislav Petkov <bp@...e.de>, Carel Si <beibei.si@...el.com>
CC:     Joerg Roedel <jroedel@...e.de>,
        LKML <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
        <lkp@...ts.01.org>, <lkp@...el.com>
Subject: Re: [LKP] Re: [x86/mm/64] f154f29085:
 BUG:kernel_reboot-without-warning_in_boot_stage

Hi Boris,

On 12/15/2021 6:05 PM, Borislav Petkov wrote:
> On Wed, Dec 15, 2021 at 03:00:13PM +0800, Carel Si wrote:
>> We have verified by hand, still can reproduce this issue.
> 
> Ok, please give details how exactly you reproduce: host, guest, kernel
> versions, configs, machine types, i.e., /proc/cpuinfo, dmesg, etc. I'd
> like to see if I can find a similar machine here.
> 
> Also, would it be possible to upload your vmlinuz somewhere so that I
> can download it for testing?

The testing was with Qemu. And we found that the hang is related with
clang-14.

The original report showed the kernel is built with clang-14:
        # build kernel
	cd linux
	cp config-5.16.0-rc3-00003-gf154f290855b .config
	make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
	make HOSTCC=clang-14 CC=clang-14 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install


And the clang-14 generate different code comparing to clang-11. I pasted
the native_write_cr4 assembly code generated with clang-14 and clang-11 to:
https://zerobin.net/?ced930258536c677#U6et+H97oxbpdYclFvAX0F3ha0rCJctLE53mJjDKrgo=

The extra code generated by clang-14 is like:

ffffffff810b8784:       48 89 d8                mov    %rbx,%rax
ffffffff810b8787:       48 c1 e8 03             shr    $0x3,%rax
ffffffff810b878b:       48 b9 00 00 00 00 00    movabs $0xdffffc0000000000,%rcx
ffffffff810b8792:       fc ff df
ffffffff810b8795:       80 3c 08 00             cmpb   $0x0,(%rax,%rcx,1)
                 --> Qemu reboot after this instruction from x86_64_start_kernel
ffffffff810b8799:       74 08                   je     ffffffff810b87a3 <native_write_cr4+0x84>
ffffffff810b879b:       48 89 df                mov    %rbx,%rdi
ffffffff810b879e:       e8 cc 7c 64 00          callq  ffffffff8170046f <__asan_report_load8_noabort>
ffffffff810b87a3:       48 ff 03                incq   (%rbx)
ffffffff810b87a6:       5b                      pop    %rbx


Looks like KASAN related stub generated by clang-14 (KASAN_SHADOW_OFFSET and asan_report).
This function is early function called before kasan_init.

Looks like we need to disable KASAN_SANITIZE for arch/x86/kernel/cpu/common.c. So clang-14 will
be happy with this kind of early TLB flush? Thanks.


Regards
Yin, Fengwei

> 
> Thx.
>