From: Marco Elver <elver@google.com> To: Dave Hansen <dave.hansen@intel.com> Cc: glider@google.com, akpm@linux-foundation.org, catalin.marinas@arm.com, cl@linux.com, rientjes@google.com, iamjoonsoo.kim@lge.com, mark.rutland@arm.com, penberg@kernel.org, hpa@zytor.com, paulmck@kernel.org, andreyknvl@google.com, aryabinin@virtuozzo.com, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, dvyukov@google.com, edumazet@google.com, gregkh@linuxfoundation.org, mingo@redhat.com, jannh@google.com, corbet@lwn.net, keescook@chromium.org, peterz@infradead.org, cai@lca.pw, tglx@linutronix.de, will@kernel.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation Date: Tue, 8 Sep 2020 18:14:26 +0200 [thread overview] Message-ID: <20200908161426.GD61807@elver.google.com> (raw) In-Reply-To: <3e87490e-3145-da2e-4190-176017d0e099@intel.com> On Tue, Sep 08, 2020 at 08:54AM -0700, Dave Hansen wrote: > On 9/7/20 6:40 AM, Marco Elver wrote: > > +The most important parameter is KFENCE's sample interval, which can be set via > > +the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The > > +sample interval determines the frequency with which heap allocations will be > > +guarded by KFENCE. The default is configurable via the Kconfig option > > +``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` > > +disables KFENCE. > > + > > +With the Kconfig option ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number > > +of available guarded objects can be controlled. Each object requires 2 pages, > > +one for the object itself and the other one used as a guard page; object pages > > +are interleaved with guard pages, and every object page is therefore surrounded > > +by two guard pages. > > Is it hard to make these both tunable at runtime? The number of objects is quite hard, because it really complicates bookkeeping and might also have an impact on performance, which is why we prefer the statically allocated pool (like on x86, and we're trying to get it for arm64 as well). The sample interval is already tunable, just write to /sys/module/kfence/parameters/sample_interval. Although we have this (see core.c): module_param_named(sample_interval, kfence_sample_interval, ulong, IS_ENABLED(CONFIG_DEBUG_KERNEL) ? 0600 : 0400); I was wondering if it should also be tweakable on non-debug kernels, but I fear it might be abused. Sure, you need to be root to change it, but maybe I'm being overly conservative here? If you don't see huge problems with it we could just make it 0600 for all builds. > It would be nice if I hit a KFENCE error on a system to bump up the > number of objects and turn up the frequency of guarded objects to try to > hit it again. That would be a really nice feature for development > environments. Indeed, which is why we also found it might be useful to tweak sample_interval at runtime for debug-kernels. Although I don't know how much luck you'll have hitting it again. My strategy at that point would be to take the stack traces, try to construct test-cases for those code paths, and run them through KASAN (if it isn't immediately obvious what the problem is). > It would also be nice to have a counter somewhere (/proc/vmstat?) to > explicitly say how many pages are currently being used. You can check /sys/kernel/debug/kfence/stats. On a system I just booted: [root@syzkaller][~]# cat /sys/kernel/debug/kfence/stats enabled: 1 currently allocated: 18 total allocations: 105 total frees: 87 total bugs: 0 The "currently allocated" count is the currently used KFENCE objects (of 255 for the default config). > I didn't mention it elsewhere, but this work looks really nice. It has > very little impact on the core kernel and looks like a very nice tool to > have in the toolbox. I don't see any major reasons we wouldn't want to > merge after our typical bikeshedding. :) Thank you! -- Marco
WARNING: multiple messages have this Message-ID (diff)
From: Marco Elver <elver@google.com> To: Dave Hansen <dave.hansen@intel.com> Cc: mark.rutland@arm.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, will@kernel.org, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, aryabinin@virtuozzo.com, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, cai@lca.pw, iamjoonsoo.kim@lge.com Subject: Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation Date: Tue, 8 Sep 2020 18:14:26 +0200 [thread overview] Message-ID: <20200908161426.GD61807@elver.google.com> (raw) In-Reply-To: <3e87490e-3145-da2e-4190-176017d0e099@intel.com> On Tue, Sep 08, 2020 at 08:54AM -0700, Dave Hansen wrote: > On 9/7/20 6:40 AM, Marco Elver wrote: > > +The most important parameter is KFENCE's sample interval, which can be set via > > +the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The > > +sample interval determines the frequency with which heap allocations will be > > +guarded by KFENCE. The default is configurable via the Kconfig option > > +``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` > > +disables KFENCE. > > + > > +With the Kconfig option ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number > > +of available guarded objects can be controlled. Each object requires 2 pages, > > +one for the object itself and the other one used as a guard page; object pages > > +are interleaved with guard pages, and every object page is therefore surrounded > > +by two guard pages. > > Is it hard to make these both tunable at runtime? The number of objects is quite hard, because it really complicates bookkeeping and might also have an impact on performance, which is why we prefer the statically allocated pool (like on x86, and we're trying to get it for arm64 as well). The sample interval is already tunable, just write to /sys/module/kfence/parameters/sample_interval. Although we have this (see core.c): module_param_named(sample_interval, kfence_sample_interval, ulong, IS_ENABLED(CONFIG_DEBUG_KERNEL) ? 0600 : 0400); I was wondering if it should also be tweakable on non-debug kernels, but I fear it might be abused. Sure, you need to be root to change it, but maybe I'm being overly conservative here? If you don't see huge problems with it we could just make it 0600 for all builds. > It would be nice if I hit a KFENCE error on a system to bump up the > number of objects and turn up the frequency of guarded objects to try to > hit it again. That would be a really nice feature for development > environments. Indeed, which is why we also found it might be useful to tweak sample_interval at runtime for debug-kernels. Although I don't know how much luck you'll have hitting it again. My strategy at that point would be to take the stack traces, try to construct test-cases for those code paths, and run them through KASAN (if it isn't immediately obvious what the problem is). > It would also be nice to have a counter somewhere (/proc/vmstat?) to > explicitly say how many pages are currently being used. You can check /sys/kernel/debug/kfence/stats. On a system I just booted: [root@syzkaller][~]# cat /sys/kernel/debug/kfence/stats enabled: 1 currently allocated: 18 total allocations: 105 total frees: 87 total bugs: 0 The "currently allocated" count is the currently used KFENCE objects (of 255 for the default config). > I didn't mention it elsewhere, but this work looks really nice. It has > very little impact on the core kernel and looks like a very nice tool to > have in the toolbox. I don't see any major reasons we wouldn't want to > merge after our typical bikeshedding. :) Thank you! -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-08 17:34 UTC|newest] Thread overview: 152+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-07 13:40 [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 15:41 ` Jonathan Cameron 2020-09-07 15:41 ` Jonathan Cameron 2020-09-07 16:38 ` Marco Elver 2020-09-07 16:38 ` Marco Elver 2020-09-07 16:38 ` Marco Elver 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 14:57 ` Dmitry Vyukov 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:06 ` Marco Elver 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 15:48 ` Dmitry Vyukov 2020-09-10 16:22 ` Marco Elver 2020-09-10 16:22 ` Marco Elver 2020-09-10 16:22 ` Marco Elver 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 15:42 ` Dmitry Vyukov 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 16:19 ` Alexander Potapenko 2020-09-10 17:11 ` Dmitry Vyukov 2020-09-10 17:11 ` Dmitry Vyukov 2020-09-10 17:11 ` Dmitry Vyukov 2020-09-10 17:41 ` Marco Elver 2020-09-10 17:41 ` Marco Elver 2020-09-10 17:41 ` Marco Elver 2020-09-10 20:25 ` Paul E. McKenney 2020-09-10 20:25 ` Paul E. McKenney 2020-09-15 13:57 ` SeongJae Park 2020-09-15 13:57 ` SeongJae Park 2020-09-15 14:14 ` Marco Elver 2020-09-15 14:14 ` Marco Elver 2020-09-15 14:26 ` SeongJae Park 2020-09-15 14:26 ` SeongJae Park 2020-09-07 13:40 ` [PATCH RFC 02/10] x86, kfence: enable KFENCE for x86 Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 17:31 ` kernel test robot 2020-09-07 13:40 ` [PATCH RFC 03/10] arm64, kfence: enable KFENCE for ARM64 Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-09 15:13 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 04/10] mm, kfence: insert KFENCE hooks for SLAB Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 7:17 ` Dmitry Vyukov 2020-09-11 12:24 ` Marco Elver 2020-09-11 12:24 ` Marco Elver 2020-09-11 12:24 ` Marco Elver 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-11 13:03 ` Dmitry Vyukov 2020-09-07 13:40 ` [PATCH RFC 05/10] mm, kfence: insert KFENCE hooks for SLUB Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 06/10] kfence, kasan: make KFENCE compatible with KASAN Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 16:11 ` kernel test robot 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 7:04 ` Dmitry Vyukov 2020-09-11 13:00 ` Marco Elver 2020-09-11 13:00 ` Marco Elver 2020-09-11 13:00 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 07/10] kfence, kmemleak: make KFENCE compatible with KMEMLEAK Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-08 11:53 ` Catalin Marinas 2020-09-08 11:53 ` Catalin Marinas 2020-09-08 12:29 ` Alexander Potapenko 2020-09-08 12:29 ` Alexander Potapenko 2020-09-08 12:29 ` Alexander Potapenko 2020-09-07 13:40 ` [PATCH RFC 08/10] kfence, lockdep: make KFENCE compatible with lockdep Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 15:33 ` Andrey Konovalov 2020-09-07 16:33 ` Marco Elver 2020-09-07 16:33 ` Marco Elver 2020-09-07 16:33 ` Marco Elver 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 17:55 ` Andrey Konovalov 2020-09-07 18:16 ` Marco Elver 2020-09-07 18:16 ` Marco Elver 2020-09-07 18:16 ` Marco Elver 2020-09-08 15:54 ` Dave Hansen 2020-09-08 15:54 ` Dave Hansen 2020-09-08 16:14 ` Marco Elver [this message] 2020-09-08 16:14 ` Marco Elver 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:14 ` Dmitry Vyukov 2020-09-11 7:46 ` Marco Elver 2020-09-11 7:46 ` Marco Elver 2020-09-11 7:46 ` Marco Elver 2020-09-07 13:40 ` [PATCH RFC 10/10] kfence: add test suite Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 13:40 ` Marco Elver 2020-09-07 18:37 ` kernel test robot 2020-09-08 11:48 ` [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Vlastimil Babka 2020-09-08 11:48 ` Vlastimil Babka 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 12:16 ` Alexander Potapenko 2020-09-08 14:40 ` Vlastimil Babka 2020-09-08 14:40 ` Vlastimil Babka 2020-09-08 15:21 ` Marco Elver 2020-09-08 15:21 ` Marco Elver 2020-09-08 14:52 ` Dave Hansen 2020-09-08 14:52 ` Dave Hansen 2020-09-08 15:31 ` Marco Elver 2020-09-08 15:31 ` Marco Elver 2020-09-08 15:36 ` Vlastimil Babka 2020-09-08 15:36 ` Vlastimil Babka 2020-09-08 15:56 ` Marco Elver 2020-09-08 15:56 ` Marco Elver 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 7:35 ` Dmitry Vyukov 2020-09-11 12:03 ` Marco Elver 2020-09-11 12:03 ` Marco Elver 2020-09-11 12:03 ` Marco Elver 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:09 ` Dmitry Vyukov 2020-09-11 13:33 ` Marco Elver 2020-09-11 13:33 ` Marco Elver 2020-09-11 13:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-11 16:33 ` Marco Elver 2020-09-08 15:37 ` Dave Hansen 2020-09-08 15:37 ` Dave Hansen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200908161426.GD61807@elver.google.com \ --to=elver@google.com \ --cc=akpm@linux-foundation.org \ --cc=andreyknvl@google.com \ --cc=aryabinin@virtuozzo.com \ --cc=bp@alien8.de \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=cl@linux.com \ --cc=corbet@lwn.net \ --cc=dave.hansen@intel.com \ --cc=dave.hansen@linux.intel.com \ --cc=dvyukov@google.com \ --cc=edumazet@google.com \ --cc=glider@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=jannh@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=luto@kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=paulmck@kernel.org \ --cc=penberg@kernel.org \ --cc=peterz@infradead.org \ --cc=rientjes@google.com \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.