linux-kernel - Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for NO

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: <alpine.DEB.2.21.1809101147500.1402@nanos.tec.linutronix.de>
Date:   Mon, 10 Sep 2018 11:53:39 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Feng Tang <feng.tang@...el.com>
cc:     Michal Hocko <mhocko@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Ingo Molnar <mingo@...e.hu>,
        "H . Peter Anvin" <hpa@...ux.intel.com>,
        Yinghai Lu <yinghai@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for
 NO_BOOTMEM

On Mon, 10 Sep 2018, Feng Tang wrote:
> On Fri, Sep 07, 2018 at 12:52:17PM +0200, Thomas Gleixner wrote:
> > You really want to add a proper sanity check for this. The static stuff has
> > to cover the fixmap. Just making it work for this particular case is sloppy
> > at best as the next larger change of the fixmap will just bring the problem
> > back.
> Yes, agree.
> 
> Since the issue happens very early before any serial console, I can only think
> of a build time check.

Of course. That's obvious. The size _IS_ known at build time.

> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> index e848a4811785..fc172551048a 100644
> --- a/arch/x86/mm/pgtable.c
> +++ b/arch/x86/mm/pgtable.c
> @@ -637,6 +637,19 @@ void __native_set_fixmap(enum fixed_addresses idx, pte_t pte)
>  {
>  	unsigned long address = __fix_to_virt(idx);
>  
> +#ifdef CONFIG_X86_64
> +	/*
> +	 * In arch/x86/kernel/head_64.S, the static page table
> +	 * has been setup for 4M space [-12M, -8M]
> +	 *	0xFFFFFFFFFF400000 ~ 0xFFFFFFFFFF7FFFFF
> +	 * Add a sanity check whether fixed_address crosses
> +	 * the boundary.
> +	 */
> +	#define FIXMAP_STATIC_PGTABLE_START	0xFFFFFFFFFF400000

Errm what? This is beyond hillarious, really. What helps that if I remove
that second FIXMAP entry in head_64.S?

The size of the fixmap is known at compile time and it is known when
building head_64.S. So the obvious check is to check right there where the
static pagetable is set up and where you know how many entries you set up
whether it's covering the full size or not and err out there.

Thanks,

	tglx