Benjamin Herrenschmidt <b...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
