Re: [PATCH v2 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support

On 12/11/19 5:24 PM, Daniel Axtens wrote: > Hi Balbir, > > +Discontiguous memory can occur when you have a machine with memory spread > +across multiple nodes. For example, on a Talos II with 64GB of RAM: > + > + - 32GB runs from 0x0 to 0x_0008__, > + - then

Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory

On 11/29/19 2:47 PM, Dmitry Vyukov wrote: > On Fri, Nov 29, 2019 at 12:38 PM Andrey Ryabinin > wrote: >>>>> >>>>> >>>>> Not sure if it's the same or not. Is it addressed by something in flight? >>>>>

Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory

On 11/29/19 2:02 PM, Dmitry Vyukov wrote: > On Fri, Nov 29, 2019 at 11:58 AM Dmitry Vyukov wrote: >> >> On Fri, Nov 29, 2019 at 11:43 AM Dmitry Vyukov wrote: >>> >>> On Tue, Nov 19, 2019 at 10:54 AM Andrey Ryabinin >>> wrote: >>>> On

Re: [PATCH v11 1/4] kasan: support backing vmalloc space with real shadow memory

On 11/18/19 6:29 AM, Daniel Axtens wrote: > Qian Cai writes: > >> On Thu, 2019-10-31 at 20:39 +1100, Daniel Axtens wrote: >>> /* >>> * In this function, newly allocated vm_struct has VM_UNINITIALIZED >>> * flag. It means that vm_struct is not fully initialized. >>> @@ -3377,6

Re: [PATCH v11 0/4] kasan: support backing vmalloc space with real shadow memory

On 10/31/19 12:39 PM, Daniel Axtens wrote: > Daniel Axtens (4): > kasan: support backing vmalloc space with real shadow memory > kasan: add test for vmalloc > fork: support VMAP_STACK with KASAN_VMALLOC > x86/kasan: support KASAN_VMALLOC > > Documentation/dev-tools/kasan.rst | 63

Re: [PATCH v10 4/5] x86/kasan: support KASAN_VMALLOC

On 10/30/19 4:50 PM, Daniel Axtens wrote: > Andrey Ryabinin writes: > >> On 10/29/19 7:20 AM, Daniel Axtens wrote: >>> In the case where KASAN directly allocates memory to back vmalloc >>> space, don't map the early shadow page over it. >>> >

Re: [PATCH v10 5/5] kasan debug: track pages allocated for vmalloc shadow

On 10/29/19 7:20 AM, Daniel Axtens wrote: > Provide the current number of vmalloc shadow pages in > /sys/kernel/debug/kasan/vmalloc_shadow_pages. > I wouldn't merge this. I don't see use-case for this, besides testing this patch set. And I think that number should be possible to extract via

Re: [PATCH v10 4/5] x86/kasan: support KASAN_VMALLOC

ding shadow (yet), we only install pgd/p4d. I guess we could just use NUMA_NO_NODE. The rest looks ok, so with that fixed: Reviewed-by: Andrey Ryabinin

Re: [PATCH v10 3/5] fork: support VMAP_STACK with KASAN_VMALLOC

ukov > Signed-off-by: Daniel Axtens > --- Reviewed-by: Andrey Ryabinin > > diff --git a/kernel/fork.c b/kernel/fork.c > index 954e875e72b1..a6e5249ad74b 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -94,6 +94,7 @@ > #include > #include > #include >

Re: [PATCH v10 2/5] kasan: add test for vmalloc

On 10/29/19 7:20 AM, Daniel Axtens wrote: > Test kasan vmalloc support by adding a new test to the module. > > Signed-off-by: Daniel Axtens > Reviewed-by: Andrey Ryabinin

Re: [PATCH v10 1/5] kasan: support backing vmalloc space with real shadow memory

ark Rutland > Signed-off-by: Mark Rutland [shadow rework] > Signed-off-by: Daniel Axtens Small nit bellow, otherwise looks fine: Reviewed-by: Andrey Ryabinin > static __always_inline bool > @@ -1196,8 +1201,8 @@ static void free_vmap_area(struct vmap_area *va

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

On 10/16/19 4:22 PM, Mark Rutland wrote: > Hi Andrey, > > On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote: >> On 10/14/19 4:57 PM, Daniel Axtens wrote: >>>>> + /* >>>>> + * Ensure poisoning is visible before the sh

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

On 10/14/19 4:57 PM, Daniel Axtens wrote: > Hi Andrey, > > >>> + /* >>> +* Ensure poisoning is visible before the shadow is made visible >>> +* to other CPUs. >>> +*/ >>> + smp_wmb(); >> >> I'm not quite understand what this barrier do and why it needed. >> And if it's really

Re: [PATCH v8 1/5] kasan: support backing vmalloc space with real shadow memory

On 10/1/19 9:58 AM, Daniel Axtens wrote: > core_initcall(kasan_memhotplug_init); > #endif > + > +#ifdef CONFIG_KASAN_VMALLOC > +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr, > + void *unused) > +{ > + unsigned long page; > +

Re: [RFC PATCH v2 3/3] kasan: add interceptors for all string functions

On 4/2/19 12:43 PM, Christophe Leroy wrote: > Hi Dmitry, Andrey and others, > > Do you have any comments to this series ? > I don't see justification for adding all these non-instrumented functions. We need only some subset of these functions and only on powerpc so far. Arches that don't

Re: BUG: KASAN: stack-out-of-bounds

On 2/28/19 12:27 PM, Dmitry Vyukov wrote: > On Thu, Feb 28, 2019 at 10:22 AM Andrey Ryabinin > wrote: >> >> >> >> On 2/27/19 4:11 PM, Christophe Leroy wrote: >>> >>> >>> Le 27/02/2019 à 10:19, Andrey Ryabinin a écrit : &

Re: BUG: KASAN: stack-out-of-bounds

On 2/27/19 4:11 PM, Christophe Leroy wrote: > > > Le 27/02/2019 à 10:19, Andrey Ryabinin a écrit : >> >> >> On 2/27/19 11:25 AM, Christophe Leroy wrote: >>> With version v8 of the series implementing KASAN on 32 bits powerpc >>> (https://patchwork

Re: BUG: KASAN: stack-out-of-bounds

On 2/27/19 11:25 AM, Christophe Leroy wrote: > With version v8 of the series implementing KASAN on 32 bits powerpc > (https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94309), I'm > now able to activate KASAN on a mac99 is QEMU. > > Then I get the following reports at startup.

Re: [PATCH v5 3/3] powerpc/32: Add KASAN support

On 2/15/19 1:10 PM, Christophe Leroy wrote: > > > Le 15/02/2019 à 11:01, Andrey Ryabinin a écrit : >> >> >> On 2/15/19 11:41 AM, Christophe Leroy wrote: >>> >>> >>> Le 14/02/2019 à 23:04, Daniel Axtens a écrit : >>>>

Re: [PATCH v5 3/3] powerpc/32: Add KASAN support

On 2/15/19 11:41 AM, Christophe Leroy wrote: > > > Le 14/02/2019 à 23:04, Daniel Axtens a écrit : >> Hi Christophe, >> >>> --- a/arch/powerpc/include/asm/string.h >>> +++ b/arch/powerpc/include/asm/string.h >>> @@ -27,6 +27,20 @@ extern int memcmp(const void *,const void >>>

Re: [PATCH v4 3/3] powerpc/32: Add KASAN support

On 2/12/19 2:38 PM, Christophe Leroy wrote: > > > Le 12/02/2019 à 02:08, Daniel Axtens a écrit : >> Andrey Ryabinin writes: >> >>> >>> Christophe, you can specify KASAN_SHADOW_OFFSET either in Kconfig (e.g. >>> x86_64) or >>> in Makefi

Re: [PATCH v4 3/3] powerpc/32: Add KASAN support

On 2/12/19 4:08 AM, Daniel Axtens wrote: > Andrey Ryabinin writes: > >> On 2/11/19 3:25 PM, Andrey Konovalov wrote: >>> On Sat, Feb 9, 2019 at 12:55 PM christophe leroy >>> wrote: >>>> >>>> Hi Andrey, >>>> >>>> Le

Re: [PATCH v4 3/3] powerpc/32: Add KASAN support

On 2/11/19 3:25 PM, Andrey Konovalov wrote: > On Sat, Feb 9, 2019 at 12:55 PM christophe leroy > wrote: >> >> Hi Andrey, >> >> Le 08/02/2019 à 18:40, Andrey Konovalov a écrit : >>> On Fri, Feb 8, 2019 at 6:17 PM Christophe Leroy >>> wrote: Hi Daniel, Le 08/02/2019 à

Re: [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32

On 1/15/19 2:14 PM, Dmitry Vyukov wrote: > On Tue, Jan 15, 2019 at 8:27 AM Christophe Leroy > wrote: >> On 01/14/2019 09:34 AM, Dmitry Vyukov wrote: >>> On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy >>> wrote: >>> >>> In kernel/cputable.c, explicitly use memcpy() in order >>> to allow

Re: [PATCH v3 3/3] powerpc/32: Add KASAN support

On 1/12/19 2:16 PM, Christophe Leroy wrote: > +KASAN_SANITIZE_early_32.o := n > +KASAN_SANITIZE_cputable.o := n > +KASAN_SANITIZE_prom_init.o := n > + Usually it's also good idea to disable branch profiling - define DISABLE_BRANCH_PROFILING either in top of these files or via Makefile.

Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed

On 11/01/2018 07:32 PM, Peter Zijlstra wrote: > On Thu, Nov 01, 2018 at 03:22:15PM +, Trond Myklebust wrote: >> On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote: >>> On Thu, Nov 01, 2018 at 01:18:46PM +, Mark Rutland wrote: > > My one question (and the reason why I went with

Re: [PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

On 10/18/2017 08:14 PM, Pavel Tatashin wrote: > Thank you Andrey, I will test this patch. Should it go on top or replace the > existing patch in mm-tree? ARM and x86 should be done the same either both as > follow-ups or both replace. > It's a replacement of your patch. > Pavel > > -- >

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

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.

Re: llist code relies on undefined behaviour, upsets llvm/clang

2017-01-16 15:53 GMT+03:00 Peter Zijlstra : > On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote: >> Hi Peter, >> >> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not >> > something I've ever ran into. >> > >> > Also, I would argue that this

Re: [PATCH V2 04/10] kasan: Don't use kasan shadow pointer in generic functions

2015-08-26 11:54 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Missed to cherry-pick the updated version of this patch, before sending the series out. commit aeb324e09d95c189eda4ce03790da94b535d1dfc Author: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Date: Fri Aug 14

Re: [PATCH V2 05/10] kasan: Enable arch to hook into kasan callbacks.

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: We add enable/disable callbacks in this patch which architecture can implemement. We will use this in the later patches for architecture like ppc64, that cannot have early zero page kasan shadow region for the entire

Re: [PATCH V2 06/10] kasan: Allow arch to overrride kasan shadow offsets

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Some archs may want to provide kasan shadow memory as a constant offset from the address. Such arch even though cannot use inline kasan support, they can work with outofline kasan support. Signed-off-by: Aneesh Kumar

Re: [PATCH V2 07/10] kasan: Make INLINE KASan support arch selectable

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Some of the archs, may find it difficult to support inline KASan mode. Add HAVE_ARCH_KASAN_INLINE so that we can disable inline support at config time. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com

Re: [PATCH V2 09/10] kasan: Prevent deadlock in kasan reporting

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: We we end up calling kasan_report in real mode, our shadow mapping for even spinlock variable will show poisoned. Generally I agree with this patch. We should disable reports when we print report as early as possible

Re: [PATCH V2 10/10] powerpc/mm: kasan: Add kasan support for ppc64

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: + k_start = (unsigned long)kasan_mem_to_shadow(start); + k_end = (unsigned long)kasan_mem_to_shadow(end); + for (; k_start k_end; k_start += page_size) { +

Re: [PATCH V2 00/10] KASan ppc64 support

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.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

Re: [PATCH V2 02/10] kasan: MODULE_VADDR is not available on all archs

2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Conditionalize the check using #ifdef Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- mm/kasan/report.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git

Re: [PATCH V2 03/10] kasan: Rename kasan_enabled to kasan_report_enabled

...@linux.vnet.ibm.com Reviewed-by: Andrey Ryabinin ryabinin@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH V1 7/8] powerpc/mm: kasan: Add kasan support for ppc64

2015-08-18 8:36 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Andrey Ryabinin ryabinin@gmail.com writes: 2015-08-17 15:13 GMT+03:00 Andrey Ryabinin ryabinin@gmail.com: Did you disable stack instrumentation (in scripts/Makefile.kasa), or you version of gcc doesn't

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

2015-08-18 12:21 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Andrey Ryabinin ryabinin@gmail.com writes: 2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Andrey Ryabinin ryabinin@gmail.com writes: But that is introducting conditionals

Re: [RFC PATCH V1 4/8] kasan: Don't use kasan shadow pointer in generic functions

2015-08-18 8:29 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Andrey Ryabinin ryabinin@gmail.com writes: On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote: We can't use generic functions like print_hex_dump to access kasan shadow region. This require us to setup another kasan

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

2015-08-18 8:42 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Andrey Ryabinin ryabinin@gmail.com writes: 2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: Because of the above I concluded that we may not be able to do inline instrumentation. Now

Re: [RFC PATCH V1 7/8] powerpc/mm: kasan: Add kasan support for ppc64

On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote: We use the region with region ID 0xe as the kasan shadow region. Since we use hash page table, we can't have the early zero page based shadow region support. Hence we disable kasan in the early code and runtime enable this. We could imporve the

Re: [RFC PATCH V1 7/8] powerpc/mm: kasan: Add kasan support for ppc64

2015-08-17 15:13 GMT+03:00 Andrey Ryabinin ryabinin@gmail.com: Did you disable stack instrumentation (in scripts/Makefile.kasa), or you version of gcc doesn't support it (e.g. like 4.9.x on x86) ? Because this can't work with stack instrumentation as you don't have shadow for stack

Re: [RFC PATCH V1 4/8] kasan: Don't use kasan shadow pointer in generic functions

On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote: We can't use generic functions like print_hex_dump to access kasan shadow region. This require us to setup another kasan shadow region for the address passed (kasan shadow address). Most architecture won't be able to do that. Hence remove dumping

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

2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com: 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