Re: [RFC PATCH V1 0/8] KASAN ppc64 support

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> On Mon, 2015-08-17 at 12:06 +0530, Aneesh Kumar K.V wrote:
>> Hi,
>> 
>> This patchset implements kernel address sanitizer for ppc64.
>> Since ppc64 virtual address range is divided into different regions,
>> we can't have one contigous area for the kasan shadow range. Hence
>> we don't support the INLINE kasan instrumentation. With Outline
>> instrumentation, we override the shadow_to_mem and mem_to_shadow
>> callbacks, so that we map only the kernel linear range (ie,
>> region with ID 0xc). For region with ID 0xd and 0xf (vmalloc
>> and vmemmap ) we return the address of the zero page. This
>> works because kasan doesn't track both vmemmap and vmalloc address.
> So bear with me, I don't know anything about KASAN, but if you want a
> shadow, can't you just add a fixed offset to the address and thus
> effectively shadow each region independently while keeping the inline
> helpers ?
>

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 like

0xc000000000000000 -> 0xe000000000000000 

ie, shadow offset now is 0xc800000000000000

For inline instrumentation, we need to have a constant shadow offset. We
can't use the same shadow offset for region 0xd and 0xf because, the
mapping would then end up as
vmalloc:
0xc800000000000000 +  (0xd000000000000000ULL >> 3)  
0xe200000000000000

vmemmap:
0xc800000000000000 +  (0xf000000000000000ULL >> 3)  
0xe600000000000000

and we can't have that logical address range, because our valid ranges
are

0xc000000000000000 - 0xc0003fffffffffff 
0xd000000000000000 - 0xd0003fffffffffff 
0xe000000000000000 - 0xe0003fffffffffff 
0xf000000000000000 - 0xf0003fffffffffff 
 
Because of the above I concluded that we may not be able to do
inline instrumentation. Now if we are not doing inline instrumentation,
we can simplify kasan support by not creating a shadow mapping at all
for vmalloc and vmemmap region. Hence the idea of returning the address
of a zero page for anything other than kernel linear map region.

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.


NOTE:
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