From: Marco Elver <elver@google.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Potapenko <glider@google.com>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Mark Rutland <mark.rutland@arm.com>, Pekka Enberg <penberg@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>, "Paul E. McKenney" <paulmck@kernel.org>, Andrey Konovalov <andreyknvl@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, Eric Dumazet <edumazet@google.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@redhat.com>, Jann Horn <jannh@google.com>, Jonathan Corbet <corbet@lwn.net>, Kees Cook <keescook@chromium.org>, Peter Zijlstra <peterz@infradead.org>, Qian Cai <cai@lca.pw>, Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will@kernel.org>, "the arch/x86 maintainers" <x86@kernel.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux-MM <linux-mm@kvack.org> Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Thu, 10 Sep 2020 17:06:25 +0200 [thread overview] Message-ID: <CANpmjNN7qAtnUmibwGJEnxd+UcjBM1WeocoLeW0SO24NW3SkVA@mail.gmail.com> (raw) In-Reply-To: <CACT4Y+aBpeQYOWGrCoaJ=HAa0BsSekyL88kcLBTGwc--C+Ch0w@mail.gmail.com> On Thu, 10 Sep 2020 at 16:58, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Mon, Sep 7, 2020 at 3:41 PM Marco Elver <elver@google.com> wrote: > > +config KFENCE_NUM_OBJECTS > > + int "Number of guarded objects available" > > + default 255 > > + range 1 65535 > > + help > > + The number of guarded objects available. For each KFENCE object, 2 > > + pages are required; with one containing the object and two adjacent > > + ones used as guard pages. > > Hi Marco, > > Wonder if you tested build/boot with KFENCE_NUM_OBJECTS=65535? Can a > compiler create such a large object? Indeed, I get a "ld: kernel image bigger than KERNEL_IMAGE_SIZE". Let's lower it to something more reasonable. The main reason to have the limit is to constrain random configs and avoid the inevitable error reports. > > +config KFENCE_FAULT_INJECTION > > + int "Fault injection for stress testing" > > + default 0 > > + depends on EXPERT > > + help > > + The inverse probability with which to randomly protect KFENCE object > > + pages, resulting in spurious use-after-frees. The main purpose of > > + this option is to stress-test KFENCE with concurrent error reports > > + and allocations/frees. A value of 0 disables fault injection. > > I would name this differently. "FAULT_INJECTION" is already taken for > a different thing, so it's a bit confusing. > KFENCE_DEBUG_SOMETHING may be a better name. > It would also be good to make it very clear in the short description > that this is for testing of KFENCE itself. When I configure syzbot I > routinely can't figure out if various DEBUG configs detect user > errors, or enable additional unit tests, or something else. Makes sense, we'll change the name. > Maybe it should depend on DEBUG_KERNEL as well? EXPERT selects DEBUG_KERNEL, so depending on DEBUG_KERNEL doesn't make sense. > > +/* > > + * Get the canary byte pattern for @addr. Use a pattern that varies based on the > > + * lower 3 bits of the address, to detect memory corruptions with higher > > + * probability, where similar constants are used. > > + */ > > +#define KFENCE_CANARY_PATTERN(addr) ((u8)0xaa ^ (u8)((unsigned long)addr & 0x7)) > > (addr) in macro body Done for v2. > > + seq_con_printf(seq, > > + "kfence-#%zd [0x" PTR_FMT "-0x" PTR_FMT > > PTR_FMT is only used in this file, should it be declared in report.c? It's also used by the test. > Please post example reports somewhere. It's hard to figure out all > details of the reporting/formatting. They can be seen in Documentation added later in the series (also viewable here: https://github.com/google/kasan/blob/kfence/Documentation/dev-tools/kfence.rst) Thank you! -- Marco
WARNING: multiple messages have this Message-ID (diff)
From: Marco Elver <elver@google.com> To: Dmitry Vyukov <dvyukov@google.com> Cc: Mark Rutland <mark.rutland@arm.com>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Dave Hansen <dave.hansen@linux.intel.com>, Linux-MM <linux-mm@kvack.org>, Eric Dumazet <edumazet@google.com>, Alexander Potapenko <glider@google.com>, "H. Peter Anvin" <hpa@zytor.com>, Christoph Lameter <cl@linux.com>, Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>, the arch/x86 maintainers <x86@kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Ingo Molnar <mingo@redhat.com>, David Rientjes <rientjes@google.com>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Kees Cook <keescook@chromium.org>, "Paul E. McKenney" <paulmck@kernel.org>, Jann Horn <jannh@google.com>, Andrey Konovalov <andreyknvl@google.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andrew Morton <akpm@linux-foundation.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, Pekka Enberg <penberg@kernel.org>, Qian Cai <cai@lca.pw>, Joonsoo Kim <iamjoonsoo.kim@lge.com> Subject: Re: [PATCH RFC 01/10] mm: add Kernel Electric-Fence infrastructure Date: Thu, 10 Sep 2020 17:06:25 +0200 [thread overview] Message-ID: <CANpmjNN7qAtnUmibwGJEnxd+UcjBM1WeocoLeW0SO24NW3SkVA@mail.gmail.com> (raw) In-Reply-To: <CACT4Y+aBpeQYOWGrCoaJ=HAa0BsSekyL88kcLBTGwc--C+Ch0w@mail.gmail.com> On Thu, 10 Sep 2020 at 16:58, Dmitry Vyukov <dvyukov@google.com> wrote: > > On Mon, Sep 7, 2020 at 3:41 PM Marco Elver <elver@google.com> wrote: > > +config KFENCE_NUM_OBJECTS > > + int "Number of guarded objects available" > > + default 255 > > + range 1 65535 > > + help > > + The number of guarded objects available. For each KFENCE object, 2 > > + pages are required; with one containing the object and two adjacent > > + ones used as guard pages. > > Hi Marco, > > Wonder if you tested build/boot with KFENCE_NUM_OBJECTS=65535? Can a > compiler create such a large object? Indeed, I get a "ld: kernel image bigger than KERNEL_IMAGE_SIZE". Let's lower it to something more reasonable. The main reason to have the limit is to constrain random configs and avoid the inevitable error reports. > > +config KFENCE_FAULT_INJECTION > > + int "Fault injection for stress testing" > > + default 0 > > + depends on EXPERT > > + help > > + The inverse probability with which to randomly protect KFENCE object > > + pages, resulting in spurious use-after-frees. The main purpose of > > + this option is to stress-test KFENCE with concurrent error reports > > + and allocations/frees. A value of 0 disables fault injection. > > I would name this differently. "FAULT_INJECTION" is already taken for > a different thing, so it's a bit confusing. > KFENCE_DEBUG_SOMETHING may be a better name. > It would also be good to make it very clear in the short description > that this is for testing of KFENCE itself. When I configure syzbot I > routinely can't figure out if various DEBUG configs detect user > errors, or enable additional unit tests, or something else. Makes sense, we'll change the name. > Maybe it should depend on DEBUG_KERNEL as well? EXPERT selects DEBUG_KERNEL, so depending on DEBUG_KERNEL doesn't make sense. > > +/* > > + * Get the canary byte pattern for @addr. Use a pattern that varies based on the > > + * lower 3 bits of the address, to detect memory corruptions with higher > > + * probability, where similar constants are used. > > + */ > > +#define KFENCE_CANARY_PATTERN(addr) ((u8)0xaa ^ (u8)((unsigned long)addr & 0x7)) > > (addr) in macro body Done for v2. > > + seq_con_printf(seq, > > + "kfence-#%zd [0x" PTR_FMT "-0x" PTR_FMT > > PTR_FMT is only used in this file, should it be declared in report.c? It's also used by the test. > Please post example reports somewhere. It's hard to figure out all > details of the reporting/formatting. They can be seen in Documentation added later in the series (also viewable here: https://github.com/google/kasan/blob/kfence/Documentation/dev-tools/kfence.rst) 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-10 16:30 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 [this message] 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 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=CANpmjNN7qAtnUmibwGJEnxd+UcjBM1WeocoLeW0SO24NW3SkVA@mail.gmail.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@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.