linux-kernel - Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86

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] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2022 20:06:15 +0800
From:   Qu Wenruo <quwenruo.btrfs@....com>
To:     Willy Tarreau <w@....eu>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        stable <stable@...r.kernel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-x86_64@...r.kernel.org
Subject: Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64
 UEFI runtime)



On 2022/8/22 19:58, Willy Tarreau wrote:
> On Mon, Aug 22, 2022 at 07:43:18PM +0800, Qu Wenruo wrote:
>> Tried to compile gcc10 from AUR, which failed to compile.
>>
>>
>> Anyway, thanks to the advice from Willy, I got the pre-built crosstool
>> (gcc 7.5) set up, with some small tweaks like disabling
>> CONFIG_RANDOMIZE_BASE to workaround the RELOCS failure, it at least
>> compiles for v4.14.0.
>>
>> Although there is still warning from test_gen_len:
>>
>>   Warning: ffffffff818158cc:	0f ff e9             	ud0    %ecx,%ebp
>>   Warning: objdump says 3 bytes, but insn_get_length() says 2
>>   Warning: arch/x86/tools/test_get_len found difference at
>> <cpu_idle_poll>:ffffffff818159b0
>
> Strange, sounds like a binutils issue though I could be wrong.

I'm using CROSS_COMPILE= option, which should cover the objdump from the
prebuilt "x86_64-linux-objdump" from that precompiled 7.5 crosstool.

>
>> And unfortunately v4.14 still fails to boot, even with GCC 7.5, which
>> provides an almost perfect (except above wanrings) build.
>>
>> I also tried to reduce the CPUid, from host-passthru to qemu64, and
>> rebuild, no change (same test_get_len wanrings, same boot failure).
>>
>> No clue at all now, would try older debian in a VM then.
>
> I suggest that instead of switching distros you should rather first
> try 4.14.0 to verify if there was a regression affecting your system.

Already tried, the v4.14 above really means v4.14.0 (aka v4.14 tag
directly from upstream, not from stable).

And the latest v4.14.290 can not boot neither, even rebuilt using that
toolchain.

> And if so, then a bisect will certainly be welcome. If it still does
> not work, then maybe a different distro could help, though I doubt it.

Will try debian for now, or even try some older hardware if I could find...

Thanks,
Qu

>
> Willy