All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: lib: use C string functions with KASAN enabled.
Date: Fri, 14 Sep 2018 16:28:01 +0100	[thread overview]
Message-ID: <20180914152800.GB6236@arm.com> (raw)
In-Reply-To: <cc08dd75-79f9-bece-8803-772123ebb0d6@virtuozzo.com>

On Tue, Sep 11, 2018 at 04:01:28PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 09/10/2018 04:06 PM, Will Deacon wrote:
> > On Mon, Sep 10, 2018 at 01:53:03PM +0100, Mark Rutland wrote:
> >> On Mon, Sep 10, 2018 at 12:33:22PM +0100, Mark Rutland wrote:
> >>> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> >>>> On 09/07/2018 05:56 PM, Will Deacon wrote:
> >>>>> I don't understand this bit: efistub uses the __pi_ prefixed
> >>>>> versions of the routines, so why do we need to declare them as weak?
> >>>>
> >>>> Weak needed because we can't have two non-weak functions with the same
> >>>> name.
> >>>>
> >>>> Alternative approach would be to never use e.g. "strlen" name for asm
> >>>> implementation of strlen() under CONFIG_KASAN=y.  But that would
> >>>> require adding some special ENDPIPROC_KASAN() macro since we want
> >>>> __pi_strlen() to point to the asm_strlen().
> >>>
> >>> Somehow, what we have today works with CONFIG_FORTIFY_SOURCE, which
> >>> AFAICT would suffer from texactly the same problem with things like
> >>> memcpy.
> >>>
> 
> FORTIFY_SOURCE seems uses "extern inline" to redefine functions.
> I obviously cannot make the whole lib/string.c 'extern inline'.
> 
> 
> >>> So either we're getting away with that by chance already (and should fix
> >>> that regardless of this patch), or this is not actually a problem.
> >>
> >> I now see those functions are marked weak in the assembly
> >> implementation; sorry for the noise.
> >>
> >> Regardless, I still think it's preferable to avoid weak wherever
> >> possible.
> > 
> > I was thinking along the same lines, but having played around with the code,
> > I agree with Andrey that this appears to be the cleanest solution.
> > 
> > Andrey -- could you respin using WEAK instead of .weak, removing any
> > redundant uses of ENTRY in the process? We might also need to throw an
> > ALIGN directive into the WEAK definition.
> > 
> 
> Actually I come up with something that looks decent, without using weak symbols, see below.
> "#ifndef CONFIG_KASAN" could be moved to the header. In that ALIAS probably should be renamed to
> something like NOKASAN_ALIAS().

Hmm, to be honest, I'd kinda got used to the version using weak symbols
and I reckon it'd be cleaner still if you respin it using WEAK.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kyeongdon Kim <kyeongdon.kim@lge.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: lib: use C string functions with KASAN enabled.
Date: Fri, 14 Sep 2018 16:28:01 +0100	[thread overview]
Message-ID: <20180914152800.GB6236@arm.com> (raw)
In-Reply-To: <cc08dd75-79f9-bece-8803-772123ebb0d6@virtuozzo.com>

On Tue, Sep 11, 2018 at 04:01:28PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 09/10/2018 04:06 PM, Will Deacon wrote:
> > On Mon, Sep 10, 2018 at 01:53:03PM +0100, Mark Rutland wrote:
> >> On Mon, Sep 10, 2018 at 12:33:22PM +0100, Mark Rutland wrote:
> >>> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> >>>> On 09/07/2018 05:56 PM, Will Deacon wrote:
> >>>>> I don't understand this bit: efistub uses the __pi_ prefixed
> >>>>> versions of the routines, so why do we need to declare them as weak?
> >>>>
> >>>> Weak needed because we can't have two non-weak functions with the same
> >>>> name.
> >>>>
> >>>> Alternative approach would be to never use e.g. "strlen" name for asm
> >>>> implementation of strlen() under CONFIG_KASAN=y.  But that would
> >>>> require adding some special ENDPIPROC_KASAN() macro since we want
> >>>> __pi_strlen() to point to the asm_strlen().
> >>>
> >>> Somehow, what we have today works with CONFIG_FORTIFY_SOURCE, which
> >>> AFAICT would suffer from texactly the same problem with things like
> >>> memcpy.
> >>>
> 
> FORTIFY_SOURCE seems uses "extern inline" to redefine functions.
> I obviously cannot make the whole lib/string.c 'extern inline'.
> 
> 
> >>> So either we're getting away with that by chance already (and should fix
> >>> that regardless of this patch), or this is not actually a problem.
> >>
> >> I now see those functions are marked weak in the assembly
> >> implementation; sorry for the noise.
> >>
> >> Regardless, I still think it's preferable to avoid weak wherever
> >> possible.
> > 
> > I was thinking along the same lines, but having played around with the code,
> > I agree with Andrey that this appears to be the cleanest solution.
> > 
> > Andrey -- could you respin using WEAK instead of .weak, removing any
> > redundant uses of ENTRY in the process? We might also need to throw an
> > ALIGN directive into the WEAK definition.
> > 
> 
> Actually I come up with something that looks decent, without using weak symbols, see below.
> "#ifndef CONFIG_KASAN" could be moved to the header. In that ALIAS probably should be renamed to
> something like NOKASAN_ALIAS().

Hmm, to be honest, I'd kinda got used to the version using weak symbols
and I reckon it'd be cleaner still if you respin it using WEAK.

Will

  reply	other threads:[~2018-09-14 15:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 17:05 [PATCH] arm64: lib: use C string functions with KASAN enabled Andrey Ryabinin
2018-09-06 17:05 ` Andrey Ryabinin
2018-09-06 17:05 ` [PATCH] lib/test_kasan: Add tests for several string/memory API functions Andrey Ryabinin
2018-09-06 17:05   ` Andrey Ryabinin
2018-09-07 14:56 ` [PATCH] arm64: lib: use C string functions with KASAN enabled Will Deacon
2018-09-07 14:56   ` Will Deacon
2018-09-07 15:48   ` Andrey Ryabinin
2018-09-07 15:48     ` Andrey Ryabinin
2018-09-10 11:33     ` Mark Rutland
2018-09-10 11:33       ` Mark Rutland
2018-09-10 12:53       ` Mark Rutland
2018-09-10 12:53         ` Mark Rutland
2018-09-10 13:06         ` Will Deacon
2018-09-10 13:06           ` Will Deacon
2018-09-11 13:01           ` Andrey Ryabinin
2018-09-11 13:01             ` Andrey Ryabinin
2018-09-14 15:28             ` Will Deacon [this message]
2018-09-14 15:28               ` Will Deacon
2018-09-20 13:56               ` [PATCH v2 1/3] linkage.h: Align weak symbols Andrey Ryabinin
2018-09-20 13:56                 ` Andrey Ryabinin
2018-09-20 13:56                 ` [PATCH v2 2/3] arm64: lib: use C string functions with KASAN enabled Andrey Ryabinin
2018-09-20 13:56                   ` Andrey Ryabinin
2018-10-29 10:29                   ` Will Deacon
2018-10-29 10:29                     ` Will Deacon
2018-10-29 11:16                     ` Andrey Ryabinin
2018-10-29 11:16                       ` Andrey Ryabinin
2018-10-29 11:20                       ` Will Deacon
2018-10-29 11:20                         ` Will Deacon
2018-09-20 13:56                 ` [PATCH v2 3/3] lib/test_kasan: Add tests for several string/memory API functions Andrey Ryabinin
2018-09-20 13:56                   ` Andrey Ryabinin
2018-10-29 10:29                 ` [PATCH v2 1/3] linkage.h: Align weak symbols Will Deacon
2018-10-29 10:29                   ` Will Deacon

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=20180914152800.GB6236@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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: link
Be 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.