linux-kernel - Re: [PATCH] mm: Avoid overlap the fixmap area on i386

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:	Tue, 28 Oct 2014 12:06:03 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Minfei Huang <mnfhuang@...il.com>
cc:	mingo@...hat.com, hpa@...or.com, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: Avoid overlap the fixmap area on i386

On Thu, 23 Oct 2014, Minfei Huang wrote:

> From: Minfei Huang <mnfhuang@...il.com>
> 
> It is a problem when configuring high memory off where the vmalloc
> reserve area could end up overlapping the early_ioremap fixmap
> area on i386.
> 
> The ordering of the VMALLOC_RESERVE space is:
> FIXADDR_TOP
>                        fixed_addresses
> FIXADDR_START
>                        early_ioremap fixed addresses
> FIXADDR_BOOT_START
>                        Persistent kmap area
> PKMAP_BASE
> VMALLOC_END
>                        Vmalloc area
> VMALLOC_START
> high_memory
> 
> The available address we can use is lower than FIXADDR_BOOT_START. So
> We will set the kmap boundary below the FIXADDR_BOOT_START, if configure
> the high memory.
> 
> If we configure the high memory, the vmalloc reserve area should end
> up to PKMAP_BASE, otherwise should end up to FIXADDR_BOOT_START.

Which is not really a problem, because the FIXADDR_BOOT area is only
used during boot for early_ioremap() and it's unused when ioremap() is
functional. vmalloc becomes available after early boot so the
FIXADDR_BOOT area is available for reuse.

Though in the highmem case the PKMAP area is not overlapping the
FIXADDR_BOOT area. So having the !highmem case use the same layout
(minus the PKMAP area) makes sense.

Acked-by: Thomas Gleixner <tglx@...utronix.de>

> Signed-off-by: Minfei Huang <mnfhuang@...il.com>
> ---
> arch/x86/include/asm/pgtable_32_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/pgtable_32_types.h b/arch/x86/include/asm/pgtable_32_types.h
> index ed5903b..2ac5fc8 100644
> --- a/arch/x86/include/asm/pgtable_32_types.h
> +++ b/arch/x86/include/asm/pgtable_32_types.h
> @@ -43,7 +43,7 @@ extern bool __vmalloc_start_set; /* set once high_memory is set */
> #ifdef CONFIG_HIGHMEM
> # define VMALLOC_END	(PKMAP_BASE - 2 * PAGE_SIZE)
> #else
> -# define VMALLOC_END	(FIXADDR_START - 2 * PAGE_SIZE)
> +# define VMALLOC_END	(FIXADDR_BOOT_START - 2 * PAGE_SIZE)
> #endif
> 
> #define MODULES_VADDR	VMALLOC_START
> -- 
> 1.8.3.1
--
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/