linux-kernel - Re: [PATCH v2 10/20] kasan: inline and rename kasan_unpoison

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANpmjNPxqOi8QCJ4VY6vfVkktEWO1=S5hcOBvTQcWhhL0L9B-w@mail.gmail.com>
Date:   Thu, 12 Nov 2020 23:20:27 +0100
From:   Marco Elver <elver@...gle.com>
To:     Andrey Konovalov <andreyknvl@...gle.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Alexander Potapenko <glider@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Evgenii Stepanov <eugenis@...gle.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Branislav Rankov <Branislav.Rankov@....com>,
        Kevin Brodsky <kevin.brodsky@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 10/20] kasan: inline and rename kasan_unpoison_memory

On Thu, 12 Nov 2020 at 21:54, Andrey Konovalov <andreyknvl@...gle.com> wrote:
>
> On Thu, Nov 12, 2020 at 8:52 PM Marco Elver <elver@...gle.com> wrote:
> >
> > On Thu, 12 Nov 2020 at 20:45, Andrey Konovalov <andreyknvl@...gle.com> wrote:
> > >
> > > On Wed, Nov 11, 2020 at 6:49 PM Marco Elver <elver@...gle.com> wrote:
> > > >
> > > > On Tue, Nov 10, 2020 at 11:20PM +0100, Andrey Konovalov wrote:
> > > > > Currently kasan_unpoison_memory() is used as both an external annotation
> > > > > and as an internal memory poisoning helper. Rename external annotation to
> > > > > kasan_unpoison_data() and inline the internal helper for hardware
> > > > > tag-based mode to avoid undeeded function calls.
> > > >
> > > > I don't understand why this needs to be renamed again. The users of
> > > > kasan_unpoison_memory() outweigh those of kasan_unpoison_slab(), of
> > > > which there seems to be only 1!
> > >
> > > The idea is to make kasan_(un)poison_memory() functions inlinable for
> > > internal use. It doesn't have anything to do with the number of times
> > > they are used.
> > >
> > > Perhaps we can drop the kasan_ prefix for the internal implementations
> > > though, and keep using kasan_unpoison_memory() externally.
> >
> > Whatever avoids changing the external interface, because it seems
> > really pointless. I can see why it's done, but it's a side-effect of
> > the various wrappers being added.
>
> It looks like unposion_memory() is already taken. Any suggestions for
> internal KASAN poisoning function names?

I still don't like that one of these functions just forwards to the
other, but we could use it to also give the external function a more
descriptive name.

I propose 2 options:

1. Name the internal helpers *poison_range().
2. Name the external function kasan_unpoison_range() instead of
kasan_unpoison_data().

Anything "memory" (or "data") in the allocators might not be too
helpful w.r.t. descriptive function names (i.e. stripping "memory"
from function names won't lessen descriptiveness given our context).
Perhaps kasan_poison_range() for the external function might in fact
improve the external interface (without looking at its arguments).

If we need to keep the internal helpers, I'd probably go so far as to
suggest renaming them to simply kasan_{poison,unpoison}(), and then
building the external kasan_{poison,unpoison}_foo() on top. But maybe
that's too much for now if it doesn't fit here. :-)

Thanks,
-- Marco