linux-kernel - Re: EFI boot crash regression (was: Re: 5.6-### doesn't 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]

Message-ID: <CAPcyv4iYSptWo42p1Lnbr4NWRiWG2sat+f3t8Q0kPeiiXHx3fg@mail.gmail.com>
Date:   Fri, 31 Jan 2020 10:48:44 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jörg Otte <jrg.otte@...il.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: EFI boot crash regression (was: Re: 5.6-### doesn't boot)

On Fri, Jan 31, 2020 at 10:37 AM Ingo Molnar <mingo@...nel.org> wrote:
>
>
> (Cc:ed Dan and Ard)
>
> * Jörg Otte <jrg.otte@...il.com> wrote:
>
> > Am Fr., 31. Jan. 2020 um 07:43 Uhr schrieb Ingo Molnar <mingo@...nel.org>:
> > >
> > >
> > > * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > >
> > > > On Thu, Jan 30, 2020 at 9:32 AM Jörg Otte <jrg.otte@...il.com> wrote:
> > > > >
> > > > > my notebook doesn't boot with current kernel. Booting stops right after
> > > > > displaying "loading initial ramdisk..". No further displays.
> > > > > Also nothing is wriiten to the logs.
> > > > >
> > > > > last known good kernel is : vmlinuz-5.5.0-00849-gb0be0eff1a5a
> > > > > first known bad kernel is : vmlinuz-5.5.0-01154-gc677124e631d
> > > >
> > > > It would be lovely if you can bisect a bit. But my merges in that
> > > > range are all from Ingo:
> > > >
> > > > Ingo Molnar (7):
> > > >     header cleanup
> > > >     objtool updates
> > > >     RCU updates
> > > >     EFI updates
> > > >     locking updates
> > > >     perf updates
> > > >     scheduler updates
> > >
> > > If I had to guess then perhaps the EFI changes look the most dangerous
> > > ones from these trees - but in principle most of these trees could
> > > contain a boot crasher/hang bug.
> > >
> > > > but not having any messages at all makes it hard to guess where it
> > > > would be.
> > >
> > > To improve debug output:
> > >
> > > Removing any 'fbcon' options in /boot/grub/grub.cfg and adding this to
> > > the boot options might improve the debug output:
> > >
> > >   earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn
> > >
> > > So for example if the relevant kernel boot entry in grub.cfg looks like
> > > this:
> > >
> > >   linux   /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro  splash $vt_handoff
> > >
> > > Then editing it to the following could in principle produce (much) more
> > > verbose boot output:
> > >
> > >   linux   /vmlinuz-5.3.0-26-generic root=UUID=1bcxabe3-0b62-4x04-b456-47cd90c0e6x4 ro earlyprintk=vga initcall_debug ignore_loglevel debug panic_on_warn $vt_handoff
> > >
> > > If this produces more output than just "loading initial ramdisk..' then a
> > > photo of the hung screen would be sufficient, no need to transcribe it.
> > >
> > > > A few bisect runs would narrow it down a fair amount. Bisecting all the
> > > > way would be even better, of course,
> > >
> > > Agreed!
> > >
> > > If compiling full kernels for bisections takes too long (for example
> > > because the .config is from a distro kernel) then running "make
> > > localmodconfig" to create a config tailored to the currently active
> > > modules will cut down significantly on build time.
> > >
> > > Also, a warning: if the normal boot log contains spurious warnings then
> > > the new 'panic_on_warn' option will cause additional trouble on good
> > > kernels.
> >
> > It's bisected.
> > The first bad commit is :
> > 1db91035d01aa8bfa2350c00ccb63d629b4041ad
> > efi: Add tracking for dynamically allocated memmaps
>
> Thanks a ton, that's very useful!
>
> I've Cc:-ed the EFI gents who are developing this code, maybe they'll
> spot the bug.

I'll take a look. Jörg, can you paste a full dmesg from a good boot?