From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751034AbdE3Itn (ORCPT ); Tue, 30 May 2017 04:49:43 -0400 Received: from mail-vk0-f45.google.com ([209.85.213.45]:33584 "EHLO mail-vk0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750908AbdE3Itk (ORCPT ); Tue, 30 May 2017 04:49:40 -0400 MIME-Version: 1.0 In-Reply-To: <2d35bbe9-e833-1bf3-ecd0-a02da63b381a@arm.com> References: <1494897409-14408-1-git-send-email-iamjoonsoo.kim@lge.com> <20170516062318.GC16015@js1304-desktop> <20170524074539.GA9697@js1304-desktop> <20170525004104.GA21336@js1304-desktop> <1131ff71-eb7a-8396-9a72-211f7077e5ec@arm.com> <2d35bbe9-e833-1bf3-ecd0-a02da63b381a@arm.com> From: Dmitry Vyukov Date: Tue, 30 May 2017 10:49:19 +0200 Message-ID: Subject: Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption To: Vladimir Murzin Cc: Joonsoo Kim , Andrew Morton , Andrey Ryabinin , Alexander Potapenko , kasan-dev , "linux-mm@kvack.org" , LKML , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , kernel-team@lge.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 30, 2017 at 10:40 AM, Vladimir Murzin wrote: > On 30/05/17 09:31, Vladimir Murzin wrote: >> [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] >> >> On 30/05/17 09:15, Dmitry Vyukov wrote: >>> On Tue, May 30, 2017 at 9:58 AM, Vladimir Murzin >>> wrote: >>>> On 29/05/17 16:29, Dmitry Vyukov wrote: >>>>> I have an alternative proposal. It should be conceptually simpler and >>>>> also less arch-dependent. But I don't know if I miss something >>>>> important that will render it non working. >>>>> Namely, we add a pointer to shadow to the page struct. Then, create a >>>>> slab allocator for 512B shadow blocks. Then, attach/detach these >>>>> shadow blocks to page structs as necessary. It should lead to even >>>>> smaller memory consumption because we won't need a whole shadow page >>>>> when only 1 out of 8 corresponding kernel pages are used (we will need >>>>> just a single 512B block). I guess with some fragmentation we need >>>>> lots of excessive shadow with the current proposed patch. >>>>> This does not depend on TLB in any way and does not require hooking >>>>> into buddy allocator. >>>>> The main downside is that we will need to be careful to not assume >>>>> that shadow is continuous. In particular this means that this mode >>>>> will work only with outline instrumentation and will need some ifdefs. >>>>> Also it will be slower due to the additional indirection when >>>>> accessing shadow, but that's meant as "small but slow" mode as far as >>>>> I understand. >>>>> >>>>> But the main win as I see it is that that's basically complete support >>>>> for 32-bit arches. People do ask about arm32 support: >>>>> https://groups.google.com/d/msg/kasan-dev/Sk6BsSPMRRc/Gqh4oD_wAAAJ >>>>> https://groups.google.com/d/msg/kasan-dev/B22vOFp-QWg/EVJPbrsgAgAJ >>>>> and probably mips32 is relevant as well. >>>>> Such mode does not require a huge continuous address space range, has >>>>> minimal memory consumption and requires minimal arch-dependent code. >>>>> Works only with outline instrumentation, but I think that's a >>>>> reasonable compromise. >>>> >>>> .. or you can just keep shadow in page extension. It was suggested back in >>>> 2015 [1], but seems that lack of stack instrumentation was "no-way"... >>>> >>>> [1] https://lkml.org/lkml/2015/8/24/573 >>> >>> Right. It describes basically the same idea. >>> >>> How is page_ext better than adding data page struct? >> >> page_ext is already here along with some other debug options ;) But page struct is also here. What am I missing? >>> It seems that memory for all page_ext is preallocated along with page >>> structs; but just the lookup is slower. >>> >> >> Yup. Lookup would look like (based on v4.0): >> >> ... >> page_ext = lookup_page_ext_begin(virt_to_page(start)); >> >> do { >> page_ext->shadow[idx++] = value; >> } while (idx < bound); >> >> lookup_page_ext_end((void *)page_ext); >> >> ... > > Correction: please, ignore that *_{begin,end} stuff - mainline only > lookup_page_ext() is only used. Note that this added code will be executed during handling of each and every memory access in kernel. Every instruction matters on that path. The additional indirection via page struct will also slow down it, but that's the cost for lower memory consumption and potentially 32-bit support. For page_ext it looks like even more overhead for no gain. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) by kanga.kvack.org (Postfix) with ESMTP id F022B6B0279 for ; Tue, 30 May 2017 04:49:40 -0400 (EDT) Received: by mail-ua0-f200.google.com with SMTP id s10so3712016uaa.10 for ; Tue, 30 May 2017 01:49:40 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id 192sor1616534vkn.29.2017.05.30.01.49.39 for (Google Transport Security); Tue, 30 May 2017 01:49:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <2d35bbe9-e833-1bf3-ecd0-a02da63b381a@arm.com> References: <1494897409-14408-1-git-send-email-iamjoonsoo.kim@lge.com> <20170516062318.GC16015@js1304-desktop> <20170524074539.GA9697@js1304-desktop> <20170525004104.GA21336@js1304-desktop> <1131ff71-eb7a-8396-9a72-211f7077e5ec@arm.com> <2d35bbe9-e833-1bf3-ecd0-a02da63b381a@arm.com> From: Dmitry Vyukov Date: Tue, 30 May 2017 10:49:19 +0200 Message-ID: Subject: Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Vladimir Murzin Cc: Joonsoo Kim , Andrew Morton , Andrey Ryabinin , Alexander Potapenko , kasan-dev , "linux-mm@kvack.org" , LKML , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , kernel-team@lge.com On Tue, May 30, 2017 at 10:40 AM, Vladimir Murzin wrote: > On 30/05/17 09:31, Vladimir Murzin wrote: >> [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] >> >> On 30/05/17 09:15, Dmitry Vyukov wrote: >>> On Tue, May 30, 2017 at 9:58 AM, Vladimir Murzin >>> wrote: >>>> On 29/05/17 16:29, Dmitry Vyukov wrote: >>>>> I have an alternative proposal. It should be conceptually simpler and >>>>> also less arch-dependent. But I don't know if I miss something >>>>> important that will render it non working. >>>>> Namely, we add a pointer to shadow to the page struct. Then, create a >>>>> slab allocator for 512B shadow blocks. Then, attach/detach these >>>>> shadow blocks to page structs as necessary. It should lead to even >>>>> smaller memory consumption because we won't need a whole shadow page >>>>> when only 1 out of 8 corresponding kernel pages are used (we will need >>>>> just a single 512B block). I guess with some fragmentation we need >>>>> lots of excessive shadow with the current proposed patch. >>>>> This does not depend on TLB in any way and does not require hooking >>>>> into buddy allocator. >>>>> The main downside is that we will need to be careful to not assume >>>>> that shadow is continuous. In particular this means that this mode >>>>> will work only with outline instrumentation and will need some ifdefs. >>>>> Also it will be slower due to the additional indirection when >>>>> accessing shadow, but that's meant as "small but slow" mode as far as >>>>> I understand. >>>>> >>>>> But the main win as I see it is that that's basically complete support >>>>> for 32-bit arches. People do ask about arm32 support: >>>>> https://groups.google.com/d/msg/kasan-dev/Sk6BsSPMRRc/Gqh4oD_wAAAJ >>>>> https://groups.google.com/d/msg/kasan-dev/B22vOFp-QWg/EVJPbrsgAgAJ >>>>> and probably mips32 is relevant as well. >>>>> Such mode does not require a huge continuous address space range, has >>>>> minimal memory consumption and requires minimal arch-dependent code. >>>>> Works only with outline instrumentation, but I think that's a >>>>> reasonable compromise. >>>> >>>> .. or you can just keep shadow in page extension. It was suggested back in >>>> 2015 [1], but seems that lack of stack instrumentation was "no-way"... >>>> >>>> [1] https://lkml.org/lkml/2015/8/24/573 >>> >>> Right. It describes basically the same idea. >>> >>> How is page_ext better than adding data page struct? >> >> page_ext is already here along with some other debug options ;) But page struct is also here. What am I missing? >>> It seems that memory for all page_ext is preallocated along with page >>> structs; but just the lookup is slower. >>> >> >> Yup. Lookup would look like (based on v4.0): >> >> ... >> page_ext = lookup_page_ext_begin(virt_to_page(start)); >> >> do { >> page_ext->shadow[idx++] = value; >> } while (idx < bound); >> >> lookup_page_ext_end((void *)page_ext); >> >> ... > > Correction: please, ignore that *_{begin,end} stuff - mainline only > lookup_page_ext() is only used. Note that this added code will be executed during handling of each and every memory access in kernel. Every instruction matters on that path. The additional indirection via page struct will also slow down it, but that's the cost for lower memory consumption and potentially 32-bit support. For page_ext it looks like even more overhead for no gain. -- 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: email@kvack.org