All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Greg Hackmann <ghackmann@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <mmarek@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"open list:KERNEL BUILD + fi..." <linux-kbuild@vger.kernel.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Michael Davidson <md@google.com>
Subject: Re: [PATCH 1/4] kasan: support alloca() poisoning
Date: Fri, 14 Jul 2017 08:13:33 +0200	[thread overview]
Message-ID: <CACT4Y+Yo1gKVJQF74kG5gZ60Qmzo65=6NLnN69ybd+QtzfAi1w@mail.gmail.com> (raw)
In-Reply-To: <c7160aca-a203-e3d8-eb49-b051aff78f0e@google.com>

On Fri, Jul 14, 2017 at 12:40 AM, Greg Hackmann <ghackmann@google.com> wrote:
> Hi,
>
> Thanks for taking a look at this patchstack.  I apologize for the delay in
> responding.
>
> On 07/10/2017 01:44 AM, Dmitry Vyukov wrote:
>>>
>>> +
>>> +       const void *left_redzone = (const void *)(addr -
>>> +                       KASAN_ALLOCA_REDZONE_SIZE);
>>> +       const void *right_redzone = (const void *)(addr +
>>> rounded_up_size);
>>
>>
>> Please check that size is rounded to KASAN_ALLOCA_REDZONE_SIZE. That's
>> the expectation, right? That can change is clang silently.
>>
>>> +       kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
>>> +                       KASAN_ALLOCA_LEFT);
>>> +       kasan_poison_shadow(right_redzone,
>>> +                       padding_size + KASAN_ALLOCA_REDZONE_SIZE,
>>> +                       KASAN_ALLOCA_RIGHT);
>>
>>
>> We also need to poison the unaligned part at the end of the object
>> from size to rounded_up_size. You can see how we do it for heap
>> objects.
>
>
> The expectation is that `size' is the exact size of the alloca()ed object.
> `rounded_up_size' then adds the 0-7 bytes needed to adjust the size to the
> ASAN shadow scale.  So `addr + rounded_up_size' should be the correct place
> to start poisoning.


We need to start poisoning at addr+size exactly.
Asan shadow scheme supports this. It's not possible to poison
beginning of an aligned 8-byte block, but leave tail unpoisoned. But
it is possible to poison tail of an aligned 8-byte block and leave
beginning unpoisoned. Look at what we do for kmalloc.


> In retrospect this part of the code was pretty confusing.  How about this?
> I think its intent is clearer, plus it's a closer match for the description
> in my commit message:
>
>         unsigned long left_redzone_start;
>         unsigned long object_end;
>         unsigned long right_redzone_start, right_redzone_end;
>
>         left_redzone_start = addr - KASAN_ALLOCA_REDZONE_SIZE;
>         kasan_poison_shadow((const void *)left_redzone_start,
>                         KASAN_ALLOCA_REDZONE_SIZE,
>                         KASAN_ALLOCA_LEFT);
>
>         object_end = round_up(addr + size, KASAN_SHADOW_SCALE_SIZE);
>         right_redzone_start = round_up(object_end,
> KASAN_ALLOCA_REDZONE_SIZE);
>         right_redzone_end = right_redzone_start + KASAN_ALLOCA_REDZONE_SIZE;
>         kasan_poison_shadow((const void *)object_end,
>                         right_redzone_end - object_end,
>                         KASAN_ALLOCA_RIGHT);

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Vyukov <dvyukov@google.com>
To: Greg Hackmann <ghackmann@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <mmarek@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"open list:KERNEL BUILD + fi..." <linux-kbuild@vger.kernel.org>,
	Matthias Kaehlcke <mka@chromium.org>,
	Michael Davidson <md@google.com>
Subject: Re: [PATCH 1/4] kasan: support alloca() poisoning
Date: Fri, 14 Jul 2017 08:13:33 +0200	[thread overview]
Message-ID: <CACT4Y+Yo1gKVJQF74kG5gZ60Qmzo65=6NLnN69ybd+QtzfAi1w@mail.gmail.com> (raw)
In-Reply-To: <c7160aca-a203-e3d8-eb49-b051aff78f0e@google.com>

On Fri, Jul 14, 2017 at 12:40 AM, Greg Hackmann <ghackmann@google.com> wrote:
> Hi,
>
> Thanks for taking a look at this patchstack.  I apologize for the delay in
> responding.
>
> On 07/10/2017 01:44 AM, Dmitry Vyukov wrote:
>>>
>>> +
>>> +       const void *left_redzone = (const void *)(addr -
>>> +                       KASAN_ALLOCA_REDZONE_SIZE);
>>> +       const void *right_redzone = (const void *)(addr +
>>> rounded_up_size);
>>
>>
>> Please check that size is rounded to KASAN_ALLOCA_REDZONE_SIZE. That's
>> the expectation, right? That can change is clang silently.
>>
>>> +       kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
>>> +                       KASAN_ALLOCA_LEFT);
>>> +       kasan_poison_shadow(right_redzone,
>>> +                       padding_size + KASAN_ALLOCA_REDZONE_SIZE,
>>> +                       KASAN_ALLOCA_RIGHT);
>>
>>
>> We also need to poison the unaligned part at the end of the object
>> from size to rounded_up_size. You can see how we do it for heap
>> objects.
>
>
> The expectation is that `size' is the exact size of the alloca()ed object.
> `rounded_up_size' then adds the 0-7 bytes needed to adjust the size to the
> ASAN shadow scale.  So `addr + rounded_up_size' should be the correct place
> to start poisoning.


We need to start poisoning at addr+size exactly.
Asan shadow scheme supports this. It's not possible to poison
beginning of an aligned 8-byte block, but leave tail unpoisoned. But
it is possible to poison tail of an aligned 8-byte block and leave
beginning unpoisoned. Look at what we do for kmalloc.


> In retrospect this part of the code was pretty confusing.  How about this?
> I think its intent is clearer, plus it's a closer match for the description
> in my commit message:
>
>         unsigned long left_redzone_start;
>         unsigned long object_end;
>         unsigned long right_redzone_start, right_redzone_end;
>
>         left_redzone_start = addr - KASAN_ALLOCA_REDZONE_SIZE;
>         kasan_poison_shadow((const void *)left_redzone_start,
>                         KASAN_ALLOCA_REDZONE_SIZE,
>                         KASAN_ALLOCA_LEFT);
>
>         object_end = round_up(addr + size, KASAN_SHADOW_SCALE_SIZE);
>         right_redzone_start = round_up(object_end,
> KASAN_ALLOCA_REDZONE_SIZE);
>         right_redzone_end = right_redzone_start + KASAN_ALLOCA_REDZONE_SIZE;
>         kasan_poison_shadow((const void *)object_end,
>                         right_redzone_end - object_end,
>                         KASAN_ALLOCA_RIGHT);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-07-14  6:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 22:01 [PATCH 0/4] kasan: add clang support Greg Hackmann
2017-07-06 22:01 ` Greg Hackmann
2017-07-06 22:01 ` [PATCH 1/4] kasan: support alloca() poisoning Greg Hackmann
2017-07-06 22:01   ` Greg Hackmann
2017-07-07  0:09   ` Greg Hackmann
2017-07-07  0:09     ` Greg Hackmann
2017-07-10  8:44   ` Dmitry Vyukov
2017-07-10  8:44     ` Dmitry Vyukov
2017-07-13 22:40     ` Greg Hackmann
2017-07-13 22:40       ` Greg Hackmann
2017-07-14  6:13       ` Dmitry Vyukov [this message]
2017-07-14  6:13         ` Dmitry Vyukov
2017-07-10 10:30   ` Andrey Ryabinin
2017-07-10 10:30     ` Andrey Ryabinin
2017-07-13 22:49     ` Greg Hackmann
2017-07-13 22:49       ` Greg Hackmann
2017-07-14 16:52       ` Andrey Ryabinin
2017-07-14 16:52         ` Andrey Ryabinin
2017-07-06 22:01 ` [PATCH 2/4] kasan: added functions for unpoisoning stack variables Greg Hackmann
2017-07-06 22:01   ` Greg Hackmann
2017-07-10  8:46   ` Dmitry Vyukov
2017-07-10  8:46     ` Dmitry Vyukov
2017-07-10 10:31   ` Andrey Ryabinin
2017-07-10 10:31     ` Andrey Ryabinin
2017-07-06 22:01 ` [PATCH 3/4] kasan: support LLVM-style asan parameters Greg Hackmann
2017-07-06 22:01   ` Greg Hackmann
2017-07-10  8:47   ` Dmitry Vyukov
2017-07-10  8:47     ` Dmitry Vyukov
2017-07-06 22:01 ` [PATCH 4/4] kasan: add compiler support for clang Greg Hackmann
2017-07-06 22:01   ` Greg Hackmann
2017-07-10  8:48   ` Dmitry Vyukov
2017-07-10  8:48     ` Dmitry Vyukov
2017-07-10 10:34   ` Andrey Ryabinin
2017-07-10 10:34     ` Andrey Ryabinin

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='CACT4Y+Yo1gKVJQF74kG5gZ60Qmzo65=6NLnN69ybd+QtzfAi1w@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=ghackmann@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=md@google.com \
    --cc=mka@chromium.org \
    --cc=mmarek@suse.com \
    --cc=yamada.masahiro@socionext.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 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.