linux-kernel - RE: kernel boot fail with efi earlyprintk (bisected)

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:	Fri, 22 Aug 2014 01:43:15 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	Matt Fleming <matt@...sole-pimps.org>,
	Dave Young <dyoung@...hat.com>
CC:	"Fleming, Matt" <matt.fleming@...el.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...ica.org" <devel@...ica.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Moore, Robert" <robert.moore@...el.com>
Subject: RE: kernel boot fail with efi earlyprintk (bisected)

Hi,

There is only limited entries in the x86 early mapping which is implemented by the FIXMAP.
So this means for all __init call invoked for x86, if there was a early mapping in it, it should be unmapped before exiting the __init call.

Using this rule, all __init call implementers can make sure that before entering the __init call, the limited number of FIXMAP entries is enough.

The following bisected commit just increase early mapping times from 1 to 2 in ACPICA early table handling code.
The number of 2 is less than the number of available FIXMAP entries.
And ACPICA code has ensured that all mappings are correctly unmapped after the table initialization.
So we didn't break the rule.

We can offer a workaround in ACPICA to reduce mapping count from 2 to 1 using a global option.
But since this report sounds like that the root cause is earlyprintk=efi has broken the above rule and the existing issue is triggered by this cleanup.
So could someone check the earlyprintk=efi code first?
I think earlyprintk=efi should either unmap the increased mapping or increase the number of FIXMAP entries in case earlyprintk=efi need additional early mappings.
Otherwise it will always be chances for earlyprintk=efi to break future code.

Thanks and best regards
-Lv

> From: Matt Fleming [mailto:matt@...sole-pimps.org]
> Sent: Friday, August 22, 2014 4:52 AM
> 
> On Tue, 19 Aug, at 04:16:58PM, Dave Young wrote:
> > Hi,
> >
> > 3.16 kernel boot fail with earlyprintk=efi on my laptop.
> > It keeps scrolling at the bottom line of screen.
> >
> > Bisected, the first bad commit is below:
> > commit 86dfc6f339886559d80ee0d4bd20fe5ee90450f0
> > Author: Lv Zheng <lv.zheng@...el.com>
> > Date:   Fri Apr 4 12:38:57 2014 +0800
> >
> >     ACPICA: Tables: Fix table checksums verification before installation.
> >
> >
> > I did some debugging by enabling both serial and efi earlyprintk, below is
> > some debug dmesg, seems early_ioremap fails in scroll up function due to
> > no free slot, but I'm still not sure if the debug info is right or not.
> 
> Thanks Dave, your callstack seems to make sense.
> 
> Can you also enable early_ioremap_debug so that we can figure out where
> all the FIXMAP slots are going?
> 
> --
> Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/