Re: [RFC PATCH V1 0/8] KASAN ppc64 support
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2015-08-17 10:01:39
On Mon, 2015-08-17 at 15:20 +0530, Aneesh Kumar K.V wrote:
For kernel linear mapping, our address space looks like 0xc000000000000000 - 0xc0003fffffffffff (64TB) We can't have virtual address(effective address) above that range in 0xc region. Hence in-order to shadow the linear mapping, I am using region 0xe. ie, the shadow mapping now looks liwe 0xc000000000000000 -> 0xe000000000000000
Why ? IE. Why can't you put the shadow at address +64T and have it work for everything ? .../...
Another reason why inline instrumentation is difficult is that for inline instrumentation to work, we need to create a mapping for _possible_ virtual address space before kasan is fully initialized. ie, we need to create page table entries for the shadow of the entire 64TB range, with zero page, even though we have lesser ram. We definitely can't bolt those entries. I am yet to get the shadow for kernel linear mapping to work without bolting. Also we will have to get the page table allocated for that, because we can't share page table entries. Our fault path use pte entries for storing hash slot index.
Hrm, that means we might want to start considering a page table to cover the linear mapping...
If we are ok to steal part of that 64TB range, for kasan mapping , ie we make shadow of each region part of the same region, may be we can get inline instrumentation to work. But that still doesn't solve the page table allocation overhead issue mentioned above. -aneesh