From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by kanga.kvack.org (Postfix) with ESMTP id 5CB3A8E0033 for ; Mon, 17 Dec 2018 14:33:56 -0500 (EST) Received: by mail-pg1-f199.google.com with SMTP id o9so11460880pgv.19 for ; Mon, 17 Dec 2018 11:33:56 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id f21sor22364852pgm.40.2018.12.17.11.33.54 for (Google Transport Security); Mon, 17 Dec 2018 11:33:54 -0800 (PST) MIME-Version: 1.0 References: <2bf7415e-2724-b3c3-9571-20c8b6d43b92@arm.com> In-Reply-To: From: Andrey Konovalov Date: Mon, 17 Dec 2018 20:33:42 +0100 Message-ID: Subject: Re: [PATCH v13 19/25] kasan: add hooks implementation for tag-based mode Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Vincenzo Frascino , Andrew Morton Cc: Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Christoph Lameter , Mark Rutland , Nick Desaulniers , Marc Zyngier , Dave Martin , Ard Biesheuvel , "Eric W . Biederman" , Ingo Molnar , Paul Lawrence , Geert Uytterhoeven , Arnd Bergmann , "Kirill A. Shutemov" , Greg Kroah-Hartman , Kate Stewart , Mike Rapoport , kasan-dev , "open list:DOCUMENTATION" , LKML , Linux ARM , linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Vishwath Mohan , Chintan Pandya , Jacob Bramley , Jann Horn , Ruben Ayrapetyan , Lee Smith , Kostya Serebryany , Mark Brand , Ramana Radhakrishnan , Evgenii Stepanov On Fri, Dec 14, 2018 at 1:34 PM Vincenzo Frascino wrote: > > On 12/12/18 3:04 PM, Andrey Konovalov wrote: > > On Tue, Dec 11, 2018 at 5:22 PM Vincenzo Frascino > > wrote: > >> > >> Hi Andrey, > >> > >> On 06/12/2018 12:24, Andrey Konovalov wrote: > >>> This commit adds tag-based KASAN specific hooks implementation and > >>> adjusts common generic and tag-based KASAN ones. > >>> > >>> 1. When a new slab cache is created, tag-based KASAN rounds up the size of > >>> the objects in this cache to KASAN_SHADOW_SCALE_SIZE (== 16). > >>> > >>> 2. On each kmalloc tag-based KASAN generates a random tag, sets the shadow > >>> memory, that corresponds to this object to this tag, and embeds this > >>> tag value into the top byte of the returned pointer. > >>> > >>> 3. On each kfree tag-based KASAN poisons the shadow memory with a random > >>> tag to allow detection of use-after-free bugs. > >>> > >>> The rest of the logic of the hook implementation is very much similar to > >>> the one provided by generic KASAN. Tag-based KASAN saves allocation and > >>> free stack metadata to the slab object the same way generic KASAN does. > >>> > >>> Reviewed-by: Andrey Ryabinin > >>> Reviewed-by: Dmitry Vyukov > >>> Signed-off-by: Andrey Konovalov > >>> --- > >>> mm/kasan/common.c | 116 ++++++++++++++++++++++++++++++++++++++-------- > >>> mm/kasan/kasan.h | 8 ++++ > >>> mm/kasan/tags.c | 48 +++++++++++++++++++ > >>> 3 files changed, 153 insertions(+), 19 deletions(-) > >>> > >> > >> > >> [...] > >> > >>> @@ -265,6 +290,8 @@ void kasan_cache_create(struct kmem_cache *cache, unsigned int *size, > >>> return; > >>> } > >>> > >>> + cache->align = round_up(cache->align, KASAN_SHADOW_SCALE_SIZE); > >>> + > >> > >> Did you consider to set ARCH_SLAB_MINALIGN instead of this round up? > > > > I didn't know about this macro. Looks like we can use it to do the > > same thing. Do you think it's a better solution to redefine > > ARCH_SLAB_MINALIGN to KASAN_SHADOW_SCALE_SIZE for arm64 when tag-based > > KASAN is enabled instead of adjusting cache->align in > > kasan_cache_create? > > > > Yes, I think it is better because in this way we do not need to add extra code > to do the rounding. > > Curiosity, did you try your patches with SLUB red zoning enabled? > Since the area used for the Redzone is just after the payload, aligning the > object_size independently from the allocator could have side effects, at least > if I understand well how the mechanism works. > > Setting ARCH_SLAB_MINALIGN should avoid this as well. > > What do you think? Sounds good to me. Andrew, how should proceed with this? Send another fixup patch or resend the whole series? > > >> > >> -- > >> Regards, > >> Vincenzo > >> > >> -- > >> You received this message because you are subscribed to the Google Groups "kasan-dev" group. > >> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > >> To post to this group, send email to kasan-dev@googlegroups.com. > >> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/2bf7415e-2724-b3c3-9571-20c8b6d43b92%40arm.com. > >> For more options, visit https://groups.google.com/d/optout. > > -- > Regards, > Vincenzo > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To post to this group, send email to kasan-dev@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/b99b331d-22ca-b9db-8677-4896c427ef10%40arm.com. > For more options, visit https://groups.google.com/d/optout.