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: <YbsPwyLnejLQMbTb@zn.tnic>
Date:   Thu, 16 Dec 2021 11:06:59 +0100
From:   Borislav Petkov <bp@...e.de>
To:     Yin Fengwei <fengwei.yin@...el.com>
Cc:     Carel Si <beibei.si@...el.com>, 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

On Thu, Dec 16, 2021 at 03:04:16PM +0800, Yin Fengwei wrote:
> The testing was with Qemu.

This is hardly what I asked for.

> And we found that the hang is related with clang-14.

I saw that already.

> 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

I saw that too.

> 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.

Ok, I don't understand: I asked for how exactly to reproduce and whether
you can send me your vmlinux you built with your clang-14. What I get is
some possible explanation about what might be happening.

So what do you expect me to do? Say, "oh, sure, you're right, send me a
patch" without even being able to see for myself what the root cause is?

What if it is not the kernel's fault but clang-14 is miscompiling crap
as in so many other cases?

I built clang-14 and built with your .config and it works here fine. So
why does yours fail?

Or what's the point of all this?

I mean, if you cannot send me what I ask for, you can say so. Then I can
ignore this whole report altogether and waste my time somewhere else.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ