Re: [RFC PATCH v1] powerpc/radix/kasan: KASAN support for Radix

[Andrey Ryabinin <aryabinin@virtuozzo.com>]

On 07/29/2017 05:09 PM, Balbir Singh wrote:
> This is the first attempt to implement KASAN for radix
> on powerpc64. Aneesh Kumar implemented KASAN for hash 64
> in limited mode (support only for kernel linear mapping)
> (https://lwn.net/Articles/655642/)
> 
> This patch does the following:
> 1. Defines its own zero_page,pte,pmd and pud because
> the generic PTRS_PER_PTE, etc are variables on ppc64
> book3s. Since the implementation is for radix, we use
> the radix constants. This patch uses ARCH_DEFINES_KASAN_ZERO_PTE
> for that purpose
> 2. There is a new function check_return_arch_not_ready()
> which is defined for ppc64/book3s/radix and overrides the
> checks in check_memory_region_inline() until the arch has
> done kasan setup is done for the architecture. This is needed
> for powerpc. A lot of functions are called in real mode prior
> to MMU paging init, we could fix some of this by using
> the kasan_early_init() bits, but that just maps the zero
> page and does not do useful reporting. For this RFC we
> just delay the checks in mem* functions till kasan_init()

check_return_arch_not_ready() works only for outline instrumentation
and without stack instrumentation.

I guess this works for you only because CONFIG_KASAN_SHADOW_OFFSET is not defined.
Therefore test for CFLAGS_KASAN can't pass, as '-fasan-shadow-offset= ' is invalid option,
so CFLAGS_KASAN_MINIMAL is used instead. Or maybe you just used gcc 4.9.x which don't have
full kasan support.
This is also the reason why some tests doesn't pass for you.

For stack instrumentation you'll have to implement kasan_early_init() and define CONFIG_KASAN_SHADOW_OFFSET.

> 3. This patch renames memcpy/memset/memmove to their
> equivalent __memcpy/__memset/__memmove and for files
> that skip KASAN via KASAN_SANITIZE, we use the __
> variants. This is largely based on Aneesh's patchset
> mentioned above
> 4. In paca.c, some explicit memcpy inserted by the
> compiler/linker is replaced via explicit memcpy
> for structure content copying
> 5. prom_init and a few other files have KASAN_SANITIZE
> set to n, I think with the delayed checks (#2 above)
> we might be able to work around many of them
> 6. Resizing of virtual address space is done a little
> aggressively the size is reduced to 1/4 and totally
> to 1/2. For the RFC it was considered OK, since this
> is just a debug tool for developers. This can be revisited
> in the final implementation
> 
> Tests:
> 
> I ran test_kasan.ko and it reported errors for all test
> cases except for
> 
> kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
> kasan test: kasan_stack_oob out-of-bounds on stack
> kasan test: kasan_global_oob out-of-bounds global variable
> kasan test: use_after_scope_test use-after-scope on int
> kasan test: use_after_scope_test use-after-scope on array
> 
> Based on my understanding of the test, which is an expected
> kasan bug report after each test starting with a "===" line.
> 

Right, with exception of memc_accounted_kmem_cache test.
The rest are expected to produce the kasan report unless CLFAGS_KASAN_MINIMAL
used.
use_after_scope tests also require fresh gcc 7.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>