From: Mark Rutland <mark.rutland@arm.com> To: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Will Deacon <will.deacon@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: Mon, 10 Sep 2018 12:33:22 +0100 [thread overview] Message-ID: <20180910113257.7rjj5qseu3m2tj6y@lakrids.cambridge.arm.com> (raw) In-Reply-To: <9634affa-b210-d931-e40b-6e8a20f105fc@virtuozzo.com> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote: > On 09/07/2018 05:56 PM, Will Deacon wrote: > > On Thu, Sep 06, 2018 at 08:05:33PM +0300, Andrey Ryabinin wrote: > >> ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(), > >> str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm > >> code, thus it can potentially miss many bugs. > >> > >> Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is > >> enabled, so the generic implementations from lib/string.c will be > >> used. > >> > >> Declare asm functions as weak instead of removing them because they > >> still can be used by efistub. > > > > 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. 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. Conditionally aliasing <foo> to pi_<foo> in a linker script (or header, for functions which aren't special per the c spec) seems sane to me. > Using weak seems like a way better solution to me. I would strongly prefer fixing this without weak, even if we need a ENDPRPROC_KASAN, and/or wrappers in some header file somewhere, since if something goes wrong that will fail deterministically at build time rather than silently falling back to the wrong piece of code. Thanks, Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] arm64: lib: use C string functions with KASAN enabled. Date: Mon, 10 Sep 2018 12:33:22 +0100 [thread overview] Message-ID: <20180910113257.7rjj5qseu3m2tj6y@lakrids.cambridge.arm.com> (raw) In-Reply-To: <9634affa-b210-d931-e40b-6e8a20f105fc@virtuozzo.com> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote: > On 09/07/2018 05:56 PM, Will Deacon wrote: > > On Thu, Sep 06, 2018 at 08:05:33PM +0300, Andrey Ryabinin wrote: > >> ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(), > >> str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm > >> code, thus it can potentially miss many bugs. > >> > >> Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is > >> enabled, so the generic implementations from lib/string.c will be > >> used. > >> > >> Declare asm functions as weak instead of removing them because they > >> still can be used by efistub. > > > > 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. 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. Conditionally aliasing <foo> to pi_<foo> in a linker script (or header, for functions which aren't special per the c spec) seems sane to me. > Using weak seems like a way better solution to me. I would strongly prefer fixing this without weak, even if we need a ENDPRPROC_KASAN, and/or wrappers in some header file somewhere, since if something goes wrong that will fail deterministically at build time rather than silently falling back to the wrong piece of code. Thanks, Mark.
next prev parent reply other threads:[~2018-09-10 11:33 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 [this message] 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 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=20180910113257.7rjj5qseu3m2tj6y@lakrids.cambridge.arm.com \ --to=mark.rutland@arm.com \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@linaro.org \ --cc=aryabinin@virtuozzo.com \ --cc=catalin.marinas@arm.com \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=kyeongdon.kim@lge.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --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: 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.