linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Konovalov <andreyknvl@google.com>
To: Marco Elver <elver@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	 Dmitry Vyukov <dvyukov@google.com>,
	Alexander Potapenko <glider@google.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will.deacon@arm.com>,
	 Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Evgenii Stepanov <eugenis@google.com>,
	 Branislav Rankov <Branislav.Rankov@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	 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 10/11] kasan: fix bug detection via ksize for HW_TAGS mode
Date: Tue, 12 Jan 2021 22:16:38 +0100	[thread overview]
Message-ID: <CAAeHK+y0nmeDEWG8ZMX9KmE3-MhWCtrssDJi5oHG2PFNtrDK_g@mail.gmail.com> (raw)
In-Reply-To: <X/2zBibnd/zCBFa/@elver.google.com>

On Tue, Jan 12, 2021 at 3:32 PM Marco Elver <elver@google.com> wrote:
>
> > +/*
> > + * Unlike kasan_check_read/write(), kasan_check_byte() is performed even for
> > + * the hardware tag-based mode that doesn't rely on compiler instrumentation.
> > + */
>
> We have too many check-functions, and the name needs to be more precise.
> Intuitively, I would have thought this should have access-type, i.e.
> read or write, effectively mirroring a normal access.
>
> Would kasan_check_byte_read() be better (and just not have a 'write'
> variant because we do not need it)? This would restore ksize() closest
> to what it was before (assuming reporting behaviour is fixed, too).

> >  void kasan_poison(const void *address, size_t size, u8 value);
> >  void kasan_unpoison(const void *address, size_t size);
> > -bool kasan_check_invalid_free(void *addr);
> > +bool kasan_check(const void *addr);
>
> Definitely prefer shorted names, but we're in the unfortunate situation
> of having numerous kasan_check-functions, so we probably need to be more
> precise.
>
> kasan_check() makes me think this also does reporting, but it does not
> (it seems to only check the metadata for validity).
>
> The internal function could therefore be kasan_check_allocated() (it's
> now the inverse of kasan_check_invalid_free()).

Re: kasan_check_byte():

I think the _read suffix is only making the name longer. ksize() isn't
checking that the memory is readable (or writable), it's checking that
it's addressable. At least that's the intention of the annotation, so
it makes sense to name it correspondingly despite the implementation.

Having all kasan_check_*() functions both checking and reporting makes
sense, so let's keep the kasan_check_ prefix.

What isn't obvious from the name is that this function is present for
every kasan mode. Maybe kasan_check_byte_always()? Although it also
seems too long.

But I'm OK with keeping kasan_check_byte().

Re kasan_check():

Here we can use Andrew's suggestion about the name being related to
what the function returns. And also drop the kasan_check_ prefix as
this function only does the checking.

Let's use kasan_byte_accessible() instead of kasan_check().

> > +bool __kasan_check_byte(const void *address, unsigned long ip)
> > +{
> > +     if (!kasan_check(address)) {
> > +             kasan_report_invalid_free((void *)address, ip);
>
> This is strange: why does it report an invalid free? Should this be a
> use-after-free? I think this could just call kasan_report(....) for 1
> byte, and we'd get the right report.

Will fix in v2.

Thanks!


  reply	other threads:[~2021-01-12 21:16 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 18:27 [PATCH 00/11] kasan: HW_TAGS tests support and fixes Andrey Konovalov
2021-01-05 18:27 ` [PATCH 01/11] kasan: prefix exported functions with kasan_ Andrey Konovalov
2021-01-12  7:38   ` Alexander Potapenko
2021-01-12 11:19   ` Marco Elver
2021-01-05 18:27 ` [PATCH 02/11] kasan: clarify HW_TAGS impact on TBI Andrey Konovalov
2021-01-12  7:40   ` Alexander Potapenko
2021-01-12 11:38   ` Marco Elver
2021-01-05 18:27 ` [PATCH 03/11] kasan: clean up comments in tests Andrey Konovalov
2021-01-12  7:53   ` Alexander Potapenko
2021-01-12 17:55     ` Andrey Konovalov
2021-01-12 13:07   ` Marco Elver
2021-01-05 18:27 ` [PATCH 04/11] kasan: add match-all tag tests Andrey Konovalov
2021-01-12  8:04   ` Alexander Potapenko
2021-01-12 18:10     ` Andrey Konovalov
2021-01-12 13:17   ` Marco Elver
2021-01-12 18:11     ` Andrey Konovalov
2021-01-05 18:27 ` [PATCH 05/11] kasan, arm64: allow using KUnit tests with HW_TAGS mode Andrey Konovalov
2021-01-12 19:01   ` Catalin Marinas
2021-01-15 13:11     ` Andrey Konovalov
2021-01-15 15:04   ` Vincenzo Frascino
2021-01-05 18:27 ` [PATCH 06/11] kasan: rename CONFIG_TEST_KASAN_MODULE Andrey Konovalov
2021-01-12  8:09   ` Alexander Potapenko
2021-01-12 18:26     ` Andrey Konovalov
2021-01-12 13:33   ` Marco Elver
2021-01-12 18:28     ` Andrey Konovalov
2021-01-05 18:27 ` [PATCH 07/11] kasan: add compiler barriers to KUNIT_EXPECT_KASAN_FAIL Andrey Konovalov
2021-01-12  8:18   ` Alexander Potapenko
2021-01-12 19:50     ` Andrey Konovalov
2021-01-12 19:57       ` Andrey Konovalov
2021-01-12 13:34   ` Marco Elver
2021-01-05 18:27 ` [PATCH 08/11] kasan: adopt kmalloc_uaf2 test to HW_TAGS mode Andrey Konovalov
2021-01-12  8:25   ` Alexander Potapenko
2021-01-12 20:04     ` Andrey Konovalov
2021-01-12 13:39   ` Marco Elver
2021-01-12 20:05     ` Andrey Konovalov
2021-01-05 18:27 ` [PATCH 09/11] kasan: fix memory corruption in kasan_bitops_tags test Andrey Konovalov
2021-01-12  8:30   ` Alexander Potapenko
2021-01-12 20:06     ` Andrey Konovalov
2021-01-13 12:30       ` Alexander Potapenko
2021-01-12 13:55   ` Marco Elver
2021-01-05 18:27 ` [PATCH 10/11] kasan: fix bug detection via ksize for HW_TAGS mode Andrey Konovalov
2021-01-05 21:04   ` kernel test robot
2021-01-06  0:09   ` kernel test robot
2021-01-07  0:02     ` Andrew Morton
2021-01-07  1:59       ` Andrey Konovalov
2021-01-12 14:32   ` Marco Elver
2021-01-12 21:16     ` Andrey Konovalov [this message]
2021-01-12 22:54       ` Marco Elver
2021-01-05 18:27 ` [PATCH 11/11] kasan: add proper page allocator tests Andrey Konovalov
2021-01-12  8:57   ` Alexander Potapenko
2021-01-12 14:34   ` Marco Elver

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+y0nmeDEWG8ZMX9KmE3-MhWCtrssDJi5oHG2PFNtrDK_g@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=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