From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Daniel Axtens <dja@axtens.net>
Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com
Subject: Re: [RFC PATCH v2 3/3] kasan: add interceptors for all string functions
Date: Tue, 2 Apr 2019 22:36:43 +0200 [thread overview]
Message-ID: <d5d2fa6f-c2ba-8234-e412-9c4ccd6cc4c6@c-s.fr> (raw)
In-Reply-To: <ae9262e5-0917-b7c9-52c7-fe21db2ecacb@virtuozzo.com>
Le 02/04/2019 à 18:14, Andrey Ryabinin a écrit :
>
>
> On 4/2/19 12:43 PM, Christophe Leroy wrote:
>> Hi Dmitry, Andrey and others,
>>
>> Do you have any comments to this series ?
>>
>
> I don't see justification for adding all these non-instrumented functions. We need only some subset of these functions
> and only on powerpc so far. Arches that don't use str*() that early simply doesn't need not-instrumented __str*() variant.
>
> Also I don't think that auto-replace str* to __str* for all not instrumented files is a good idea, as this will reduce KASAN coverage.
> E.g. we don't instrument slub.c but there is no reason to use non-instrumented __str*() functions there.
Ok, I didn't see it that way.
In fact I was seeing the opposite and was considering it as an
opportunity to increase KASAN coverage. E.g.: at the time being things
like the above (from arch/xtensa/include/asm/string.h) are not covered
at all I believe:
#define __HAVE_ARCH_STRCPY
static inline char *strcpy(char *__dest, const char *__src)
{
register char *__xdest = __dest;
unsigned long __dummy;
__asm__ __volatile__("1:\n\t"
"l8ui %2, %1, 0\n\t"
"s8i %2, %0, 0\n\t"
"addi %1, %1, 1\n\t"
"addi %0, %0, 1\n\t"
"bnez %2, 1b\n\t"
: "=r" (__dest), "=r" (__src), "=&r" (__dummy)
: "0" (__dest), "1" (__src)
: "memory");
return __xdest;
}
In my series, I have deactivated optimised string functions when KASAN
is selected like arm64 do. See https://patchwork.ozlabs.org/patch/1055780/
But not every arch does that, meaning that some string functions remains
not instrumented at all.
Also, I was seeing it as a way to reduce impact on performance with
KASAN. Because instrumenting each byte access of the non-optimised
string functions is a performance genocide.
>
> And finally, this series make bug reporting slightly worse. E.g. let's look at strcpy():
>
> +char *strcpy(char *dest, const char *src)
> +{
> + size_t len = __strlen(src) + 1;
> +
> + check_memory_region((unsigned long)src, len, false, _RET_IP_);
> + check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> +
> + return __strcpy(dest, src);
> +}
>
> If src is not-null terminated string we might not see proper out-of-bounds report from KASAN only a crash in __strlen().
> Which might make harder to identify where 'src' comes from, where it was allocated and what's the size of allocated area.
>
>
>> I'd like to know if this approach is ok or if it is better to keep doing as in https://patchwork.ozlabs.org/patch/1055788/
>>
> I think the patch from link is a better solution to the problem.
>
Ok, I'll stick with it then. Thanks for your feedback
Christophe
prev parent reply other threads:[~2019-04-02 20:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f13944c4e99ec2cef6d93d762e6b526e0335877f.1553785019.git.christophe.leroy@c-s.fr>
[not found] ` <51a6d9d7185de310f37ccbd7e4ebfdd6c7e9791f.1553785020.git.christophe.leroy@c-s.fr>
2019-04-02 9:43 ` [RFC PATCH v2 3/3] kasan: add interceptors for all string functions Christophe Leroy
2019-04-02 12:58 ` Dmitry Vyukov
2019-04-02 14:57 ` Christophe Leroy
2019-04-02 16:14 ` Andrey Ryabinin
2019-04-02 20:36 ` Christophe Leroy [this message]
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=d5d2fa6f-c2ba-8234-e412-9c4ccd6cc4c6@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=aneesh.kumar@linux.ibm.com \
--cc=aryabinin@virtuozzo.com \
--cc=benh@kernel.crashing.org \
--cc=dja@axtens.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.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 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).