linux-kernel - Re: [PATCH RFC] x86 early_ioremap: increase FIX_BTMAPS

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: <20140914141412.GJ18582@console-pimps.org>
Date:	Sun, 14 Sep 2014 15:14:12 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Dave Young <dyoung@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	matt.fleming@...el.com, linux-efi@...r.kernel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	devel@...ica.org, lenb@...nel.org, rafael.j.wysocki@...el.com,
	robert.moore@...el.com
Subject: Re: [PATCH RFC] x86 early_ioremap: increase FIX_BTMAPS_SLOTS to 8

On Tue, 26 Aug, at 05:06:41PM, Dave Young wrote:
> 3.16 kernel boot fail with earlyprintk=efi, 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.

[...]

> Quote reply from Lv.zheng about the early ioremap slot usage in this case:
> 
> """
> In early_efi_scroll_up(), 2 mapping entries will be used for the src/dst screen buffer.
> In drivers/acpi/acpica/tbutils.c, we've improved the early table loading code in acpi_tb_parse_root_table().
> We now need 2 mapping entries:
> 1. One mapping entry is used for RSDT table mapping. Each RSDT entry contains an address for another ACPI table.
> 2. For each entry in RSDP, we need another mapping entry to map the table to perform necessary check/override before installing it.
> 
> When acpi_tb_parse_root_table() prints something through EFI earlyprintk console, we'll have 4 mapping entries used.
> The current 4 slots setting of early_ioremap() seems to be too small for such a use case.
> """
> 
> Thus increase the slot to 8 in this patch to fix this issue.
> boot-time mappings become 512 page with this patch.
 
This analysis and solution makes sense to me, but I was really hoping
for one of the x86 maintainers to ACK the below patch. I'm happy to take
it through the EFI tree if it's not picked up into tip meanwhile.

Also, Dave, it sounds like this should be tagged for stable if the bug
has been around since v3.16?

> Signed-off-by: Dave Young <dyoung@...hat.com>
> ---
> I'm not sure if this is ok in 32bit, review and comments are appreciated.
>  arch/x86/include/asm/fixmap.h |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> Index: linux/arch/x86/include/asm/fixmap.h
> ===================================================================
> --- linux.orig/arch/x86/include/asm/fixmap.h
> +++ linux/arch/x86/include/asm/fixmap.h
> @@ -106,14 +106,14 @@ enum fixed_addresses {
>  	__end_of_permanent_fixed_addresses,
>  
>  	/*
> -	 * 256 temporary boot-time mappings, used by early_ioremap(),
> +	 * 512 temporary boot-time mappings, used by early_ioremap(),
>  	 * before ioremap() is functional.
>  	 *
> -	 * If necessary we round it up to the next 256 pages boundary so
> +	 * If necessary we round it up to the next 512 pages boundary so
>  	 * that we can have a single pgd entry and a single pte table:
>  	 */
>  #define NR_FIX_BTMAPS		64
> -#define FIX_BTMAPS_SLOTS	4
> +#define FIX_BTMAPS_SLOTS	8
>  #define TOTAL_FIX_BTMAPS	(NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
>  	FIX_BTMAP_END =
>  	 (__end_of_permanent_fixed_addresses ^


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