From: Jakub Jelinek <jakub@redhat.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: gcc-patches@gcc.gnu.org, arnd@linaro.org
Subject: Re: [PATCH] Come up with --param asan-stack-small-redzone (PR sanitizer/81715).
Date: Tue, 25 Sep 2018 12:19:00 -0000 [thread overview]
Message-ID: <20180925104022.GD8250@tucnak> (raw)
In-Reply-To: <9e39fc11-4c5b-0f84-785e-1e41306d2213@suse.cz>
On Tue, Sep 25, 2018 at 12:10:42PM +0200, Martin Liška wrote: On 9/25/18
> 11:24 AM, Jakub Jelinek wrote:
> > On Tue, Sep 25, 2018 at 11:05:30AM +0200, Martin Liška wrote:
> >> As requested in PR81715, GCC emits bigger middle redzones for small variables.
> >> It's analyzed in following comment: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c28
> >
> > First of all, does LLVM make the variable sized red zone size only for
> > automatic variables, or also for global/local statics, or for alloca?
>
> Yes, definitely for global variables, as seen here:
>
> lib/Transforms/Instrumentation/AddressSanitizer.cpp:
> 2122 Type *Ty = G->getValueType();
> 2123 uint64_t SizeInBytes = DL.getTypeAllocSize(Ty);
> 2124 uint64_t MinRZ = MinRedzoneSizeForGlobal();
> 2125 // MinRZ <= RZ <= kMaxGlobalRedzone
> 2126 // and trying to make RZ to be ~ 1/4 of SizeInBytes.
> 2127 uint64_t RZ = std::max(
> 2128 MinRZ, std::min(kMaxGlobalRedzone, (SizeInBytes / MinRZ / 4) * MinRZ));
> 2129 uint64_t RightRedzoneSize = RZ;
> 2130 // Round up to MinRZ
> 2131 if (SizeInBytes % MinRZ) RightRedzoneSize += MinRZ - (SizeInBytes % MinRZ);
> 2132 assert(((RightRedzoneSize + SizeInBytes) % MinRZ) == 0);
> 2133 Type *RightRedZoneTy = ArrayType::get(IRB.getInt8Ty(), RightRedzoneSize);
>
> So roughly to SizeInBytes / 4. Confirmed:
Changing non-automatic vars will be certainly harder. Let's do it later.
> > Have you considered also making the red zones larger for very large
> > variables?
>
> I was mainly focused on shrinking as that's limiting usage of asan-stack in KASAN.
> But I'm open for it. Would you follow what LLVM does, or do you have a specific idea how
> to growth?
Dunno if they've done some analysis before picking the current sizes, unless
we you do some I'd follow their numbers, it doesn't look totally
unreasonable, a compromise between not wasting too much for more frequent
smaller vars and for larger vars catching even larger out of bound accesses.
> > What exactly would need changing to support the 12-15 bytes long red zones
> > for 4-1 bytes long automatic vars?
> > Just asan_emit_stack_protection or something other?
>
> Primarily this function, that would need a generalization. Apart from that we're
> also doing alignment to ASAN_RED_ZONE_SIZE:
>
> prev_offset = align_base (prev_offset,
> MAX (alignb, ASAN_RED_ZONE_SIZE),
> !FRAME_GROWS_DOWNWARD);
>
> Maybe it has consequences I don't see right now?
Actually, I think even:
+ && i != n - 1
in your patch isn't correct, vars could be last even if they aren't == n - 1
or vice versa, the sorting is done by many factors, vars can go into
multiple buckets based on predicate etc.
So, rather than trying to guess what is last here it should be left to
expand_used_vars for one side, and perhaps based on whether any vars were
placed at all on the other side (don't remember if asan supports anything
but FRAME_GROWS_DOWNWARD).
> First feedback is positive:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c30
>
> It's questionable whether handling of variables 1-4B wide worth further changes.
I'd think the really small vars are quite common, isn't that the case (sure,
address taken ones will be less common, but still not rare).
Jakub
next prev parent reply other threads:[~2018-09-25 10:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-25 9:05 Martin Liška
2018-09-25 9:49 ` Jakub Jelinek
2018-09-25 10:17 ` Martin Liška
2018-09-25 10:25 ` Martin Liška
2018-09-25 12:19 ` Jakub Jelinek [this message]
2018-09-25 15:40 ` Martin Liška
2018-09-25 15:55 ` Jakub Jelinek
2018-09-26 9:34 ` Martin Liška
2018-10-09 8:53 ` Martin Liška
2018-10-23 9:17 ` Martin Liška
2018-11-13 7:50 ` Martin Liška
2018-11-28 12:01 ` Jakub Jelinek
2018-11-29 15:03 ` Martin Liška
2018-11-29 15:17 ` Jakub Jelinek
2018-11-29 16:37 ` Martin Liška
2018-11-29 16:50 ` Jakub Jelinek
2018-11-30 11:44 ` Martin Liška
2018-11-30 12:01 ` Jakub Jelinek
2018-12-01 7:36 ` [PATCH] Partial fix for asan on big endian targets (PR sanitizer/88289) Jakub Jelinek
2018-12-02 12:46 ` [committed] Fix ICE in asan_clear_shadow (PR sanitizer/88291) Jakub Jelinek
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=20180925104022.GD8250@tucnak \
--to=jakub@redhat.com \
--cc=arnd@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=mliska@suse.cz \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).