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: <CAPAsAGzm29VWz8ZvOu+fVGn4Vbj7bQZAnB11M5ZZXRTQTchj0w@mail.gmail.com>
Date:	Thu, 11 Sep 2014 00:30:10 +0400
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	Dave Hansen <dave.hansen@...el.com>
Cc:	Andrey Ryabinin <a.ryabinin@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>,
	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" <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

2014-09-10 19:46 GMT+04:00 Dave Hansen <dave.hansen@...el.com>:
> 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?
>

Yes, there is a reason for this. For inline instrumentation we need to
catch access to userspace without any additional check.
This means that we need shadow of 1 << 61 bytes and we don't have so
many addresses available. However, we could use
hole between userspace and kernelspace for that. For any address
between [0 - 0xffff800000000000], shadow address will be
in this hole, so checking shadow value will produce general protection
fault (GPF). We may even try handle GPF in a special way
and print more user-friendly report (this will be under CONFIG_KASAN of course).

But now I realized that we even if we put shadow in vmalloc, shadow
addresses  corresponding to userspace addresses
still will be in between userspace - kernelspace, so we also will get GPF.
There is the only problem I see now in such approach. Lets consider
that because of some bug in kernel we are trying to access
memory slightly bellow 0xffff800000000000. In this case kasan will try
to check some shadow which in fact is not a shadow byte at all.
It's not a big deal though, kernel will crash anyway. In only means
that debugging of such problems could be a little more complex
than without kasan.



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

Sure, I didn't bother to do it now in case if memory layout changes in
this patch not final.

>> +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.
>
>
>

-- 
Best regards,
Andrey Ryabinin
--
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/