From: Andrey Konovalov <andreyknvl@google.com>
To: Marco Elver <elver@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Dmitry Vyukov <dvyukov@google.com>,
Alexander Potapenko <glider@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Elena Petrova <lenaptr@google.com>,
Branislav Rankov <Branislav.Rankov@arm.com>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 8/8] kasan: add and integrate kasan_mode boot param
Date: Fri, 16 Oct 2020 15:10:43 +0200 [thread overview]
Message-ID: <CAAeHK+yQ+hYZSAhyGDYeVYLC-WEL35Qe=xMRtDG52G9Fu6xgXQ@mail.gmail.com> (raw)
In-Reply-To: <CANpmjNMkZc6X+Z=Bw-hOXO3n9fzq4F3mOnHgieyifkoZM=_Mdw@mail.gmail.com>
On Thu, Oct 15, 2020 at 3:56 PM Marco Elver <elver@google.com> wrote:
>
> On Wed, 14 Oct 2020 at 22:45, Andrey Konovalov <andreyknvl@google.com> wrote:
> >
[...]
> > @@ -180,6 +182,7 @@ size_t kasan_metadata_size(struct kmem_cache *cache)
> > struct kasan_alloc_meta *kasan_get_alloc_meta(struct kmem_cache *cache,
> > const void *object)
> > {
> > + WARN_ON(!static_branch_unlikely(&kasan_debug));
>
> The WARN_ON condition itself should be unlikely, so that would imply
> that the static branch here should be likely since you're negating it.
Here I was thinking that we should optimize for the production use
case, which shouldn't have kasan_debug enabled, hence the unlikely.
But technically this function shouldn't be called in production
anyway, so likely will do fine too.
> And AFAIK, this function should only be called if kasan_debug is true.
Yes, this WARN_ON is to make sure this doesn't happen.
[...]
> > +/* Whether to use syncronous or asynchronous tag checking. */
> > +static bool kasan_sync __ro_after_init;
>
> s/syncronous/synchronous/
Ack.
>
> > +static int __init early_kasan_mode(char *arg)
> > +{
> > + if (!arg)
> > + return -EINVAL;
> > +
> > + if (strcmp(arg, "on") == 0)
> > + kasan_mode = KASAN_MODE_ON;
> > + else if (strcmp(arg, "debug") == 0)
>
> s/strcmp(..) == 0/!strcmp(..)/ ?
Sounds good.
[...]
> > @@ -60,6 +111,7 @@ void kasan_set_free_info(struct kmem_cache *cache,
> > {
> > struct kasan_alloc_meta *alloc_meta;
> >
> > + WARN_ON(!static_branch_unlikely(&kasan_debug));
>
> What actually happens if any of these are called with !kasan_debug and
> the warning triggers? Is it still valid to execute the below, or
> should it bail out? Or possibly even disable KASAN entirely?
It shouldn't happen, but if it happens maybe it indeed makes sense to
disable KASAN here is a failsafe. It might be tricky to disable MTE
though, but I'll see what we can do here.
Thank you!
next prev parent reply other threads:[~2020-10-16 13:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-14 20:44 [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 1/8] kasan: simplify quarantine_put call Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 2/8] kasan: rename get_alloc/free_info Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 3/8] kasan: introduce set_alloc_info Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 4/8] kasan: unpoison stack only with CONFIG_KASAN_STACK Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 5/8] kasan: mark kasan_init_tags as __init Andrey Konovalov
2020-10-15 10:23 ` Marco Elver
2020-10-16 13:04 ` Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 6/8] kasan, arm64: move initialization message Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 7/8] arm64: kasan: Add system_supports_tags helper Andrey Konovalov
2020-10-20 6:22 ` Hillf Danton
2020-10-20 12:39 ` Andrey Konovalov
2020-10-14 20:44 ` [PATCH RFC 8/8] kasan: add and integrate kasan_mode boot param Andrey Konovalov
2020-10-15 13:56 ` Marco Elver
2020-10-16 13:10 ` Andrey Konovalov [this message]
2020-10-15 14:41 ` [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 Marco Elver
2020-10-16 13:17 ` Andrey Konovalov
2020-10-16 13:31 ` Marco Elver
2020-10-16 15:52 ` Andrey Konovalov
2020-10-19 22:51 ` Kostya Serebryany
2020-10-20 5:34 ` Dmitry Vyukov
2020-10-20 12:13 ` Andrey Konovalov
2020-10-16 15:52 ` Andrey Konovalov
2020-10-16 15:50 ` Andrey Konovalov
2020-10-19 12:23 ` Marco Elver
2020-10-20 5:20 ` Dmitry Vyukov
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='CAAeHK+yQ+hYZSAhyGDYeVYLC-WEL35Qe=xMRtDG52G9Fu6xgXQ@mail.gmail.com' \
--to=andreyknvl@google.com \
--cc=Branislav.Rankov@arm.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=catalin.marinas@arm.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=eugenis@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kevin.brodsky@arm.com \
--cc=lenaptr@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vincenzo.frascino@arm.com \
--cc=will.deacon@arm.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).