[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d459964-ce68-db1c-3d28-ae206d5ebdb0@c-s.fr>
Date: Thu, 5 Jul 2018 18:33:08 +0200
From: Christophe LEROY <christophe.leroy@....fr>
To: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc: paulus@...ba.org, linuxppc-dev@...ts.ozlabs.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 00/10] KASan ppc64 support
Hi Aneesh,
Are you still working on support for KASan for ppc64 ?
Thanks,
Christophe
Le 26/08/2015 à 19:14, Aneesh Kumar K.V a écrit :
> Andrey Ryabinin <ryabinin.a.a@...il.com> writes:
>
>> 2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>:
>>> 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.
>>>
>>> Known issues:
>>> * Kasan is not yet enabled for arch/powerpc/kvm
>>> * kexec hang
>>> * outline stack and global support
>>>
>>
>> Is there any problem with globals or you just didn't try it yet?
>> I think it should just work. You need only to add --param
>> asan-globals=0 to KBUILD_CFLAGS_MODULE
>> to disable it for modules.
>
> I am hitting BUG_ON in early vmalloc code. I still haven't got time to
> debug it further. Should get to that soon.
>
> -aneesh
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@...ts.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Powered by blists - more mailing lists