linux-kernel - Re: [RFC/PATCH v2 02/10] x86

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: <5410724B.8000803@intel.com>
Date:	Wed, 10 Sep 2014 08:46:19 -0700
From:	Dave Hansen <dave.hansen@...el.com>
To:	Andrey Ryabinin <a.ryabinin@...sung.com>,
	linux-kernel@...r.kernel.org
CC:	Dmitry Vyukov <dvyukov@...gle.com>,
	Konstantin Serebryany <kcc@...gle.com>,
	Dmitry Chernenkov <dmitryc@...gle.com>,
	Andrey Konovalov <adech.fo@...il.com>,
	Yuri Gribov <tetra2005@...il.com>,
	Konstantin Khlebnikov <koct9i@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Christoph Lameter <cl@...ux.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Vegard Nossum <vegard.nossum@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC/PATCH v2 02/10] x86_64: add KASan support

Overall, the approach here looks pretty sane.  As you noted, it would be
nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
me.  The use of the vmemmap code looks to be a nice fit.

Few nits below.

On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0xffff800000000000 - 0xffff900000000000]
> Therefore PAGE_OFFSET has to be changed from 0xffff880000000000
> to 0xffff900000000000.
...
> It would be nice to not have different PAGE_OFFSET with and without CONFIG_KASAN.
> We have big enough hole between vmemmap and esp fixup stacks.
> So how about moving all direct mapping, vmalloc and vmemmap 8TB up without
> hiding it under CONFIG_KASAN?

Is there a reason this has to be _below_ the linear map?  Couldn't we
just carve some space out of the vmalloc() area for the kasan area?


>  arch/x86/Kconfig                     |  1 +
>  arch/x86/boot/Makefile               |  2 ++
>  arch/x86/boot/compressed/Makefile    |  2 ++
>  arch/x86/include/asm/kasan.h         | 20 ++++++++++++
>  arch/x86/include/asm/page_64_types.h |  4 +++
>  arch/x86/include/asm/pgtable.h       |  7 ++++-
>  arch/x86/kernel/Makefile             |  2 ++
>  arch/x86/kernel/dumpstack.c          |  5 ++-
>  arch/x86/kernel/head64.c             |  6 ++++
>  arch/x86/kernel/head_64.S            | 16 ++++++++++
>  arch/x86/mm/Makefile                 |  3 ++
>  arch/x86/mm/init.c                   |  3 ++
>  arch/x86/mm/kasan_init_64.c          | 59 ++++++++++++++++++++++++++++++++++++
>  arch/x86/realmode/Makefile           |  2 +-
>  arch/x86/realmode/rm/Makefile        |  1 +
>  arch/x86/vdso/Makefile               |  1 +
>  include/linux/kasan.h                |  3 ++
>  lib/Kconfig.kasan                    |  1 +
>  18 files changed, 135 insertions(+), 3 deletions(-)
>  create mode 100644 arch/x86/include/asm/kasan.h
>  create mode 100644 arch/x86/mm/kasan_init_64.c

This probably deserves an update of Documentation/x86/x86_64/mm.txt, too.

> +void __init kasan_map_shadow(void)
> +{
> +	int i;
> +
> +	memcpy(early_level4_pgt, init_level4_pgt, 4096);
> +	load_cr3(early_level4_pgt);
> +
> +	clear_zero_shadow_mapping(kasan_mem_to_shadow(PAGE_OFFSET),
> +				kasan_mem_to_shadow(0xffffc80000000000UL));

This 0xffffc80000000000UL could be PAGE_OFFSET+MAXMEM.


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