public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Maxim Ostapenko <m.ostapenko@samsung.com>,
	    GCC Patches <gcc-patches@gcc.gnu.org>,
	Marek Polacek <polacek@redhat.com>,
	    Yuri Gribov <tetra2005@gmail.com>
Subject: Re: [PING^3][RFC, PATCH][ASAN] Implement dynamic allocas/VLAs sanitization.​
Date: Fri, 16 Jun 2017 07:34:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.20.1706160930240.22867@zhemvz.fhfr.qr> (raw)
In-Reply-To: <20170614173420.GD2123@tucnak>

On Wed, 14 Jun 2017, Jakub Jelinek wrote:

> Hi!
> 
> So, I've tried to look at
> struct __attribute__((aligned (N))) S { char s[N]; };
> 
> void bar (struct S *, struct S *);
> 
> void
> foo (int x)
> {
>   struct S a;
>   {
>     struct S b[x];
>     bar (&a, &b[0]);
>   }
>   {
>     struct S b[x + 4];
>     bar (&a, &b[0]);
>   }
> }
> 
> void
> baz (int x)
> {
>   struct S a;
>   struct S b[x];
>   bar (&a, &b[0]);
> }
> testcase at -O2 -fsanitize=address -DN=64 (and -DN=8) on x86_64.
> Even in *.optimized dump I'm seeing:
>   _1 = (sizetype) x_4(D);
>   # RANGE [0, 18446744073709551552] NONZERO 18446744073709551552
>   _2 = _1 * 64;
>   # RANGE [0, 31] NONZERO 31
>   _24 = _2 & 31;
>   # RANGE ~[65, 127]
>   _19 = _2 + 128;
>   # RANGE ~[65, 96]
>   _27 = _19 - _24;
>   _28 = __builtin_alloca_with_align (_27, 512);
>   _29 = _28 + 64;
>   __builtin___asan_alloca_poison (_29, _2);
> which seems to be unnecessary complicated, as _2 has nonzero
> mask of 0xffffffffffffffc0 trying to and it with 0x1f should
> yield certainly _24 = 0 and thus there is no need to subtract anything.
> 
> I wonder if this is just because the asan1 pass is fairly late and say
> ccp isn't scheduled after it.  The question is if trying to use
> gimple_build APIs instead of gimple_build_assign would help here
> (and whether we'd need some new match.pd rules to figure out
> that if you have SSA_NAME & constant and get_nonzero_bits on the
> SSA_NAME & constant is 0, then the result is 0) or not.

The gimple_build API at the moment mirrors the behavior of building
a large GENERIC expr which means it will only match-and-simplify
stmts currently building (actually not yet associated with any BB).

So if you build _2 & 31 you get that expr folded with match.pd rules
(not sure if there is any yet doing the desired simplification to _2
using get_nonzero_bits).

If you are building a stmt at a time folding built stmts would
get you the same result (but then using the gimple_build helpers
is more powerful)

> Or you could just try to check get_nonzero_bits yourself and if
> all the bits you want to mask are clear, avoid the subtraction.
> 
> Also, isn't the size used for the adjusted __builtin_alloca_with_align
> too large?  If you need _2 initially, and alignment is 64 bytes,
> then you certainly need 64 bytes before (unless we want to go into too
> low-level backend details and say that we want to allocate ret + 32
> as 64-byte aligned), but 64 bytes after it is too much, 32 bytes would be
> enough (there is no partial right zone in this case)?
> 
> On Wed, Jun 14, 2017 at 04:21:48PM +0300, Maxim Ostapenko wrote:
> > +static void
> > +handle_builtin_alloca (gcall *call, gimple_stmt_iterator *iter)
> > +{
> > +  if (!iter)
> > +    return;
> > +
> > +  gimple_seq seq = NULL;
> > +  gassign *g;
> > +  gcall *gg;
> > +  gimple_stmt_iterator gsi = *iter;
> > +  const HOST_WIDE_INT redzone_mask = ASAN_RED_ZONE_SIZE - 1;
> > +
> > +  tree last_alloca_addr = get_last_alloca_addr ();
> > +  tree callee = gimple_call_fndecl (call);
> > +  tree old_size = gimple_call_arg (call, 0);
> > +  tree ptr_type = gimple_call_lhs (call) ? TREE_TYPE (gimple_call_lhs (call))
> > +					 : ptr_type_node;
> > +  bool alloca_with_align
> > +    = DECL_FUNCTION_CODE (callee) == BUILT_IN_ALLOCA_WITH_ALIGN;
> > +  unsigned int align
> > +    = alloca_with_align ? tree_to_uhwi (gimple_call_arg (call, 1)) : 0;
> > +
> > +  /* If ALIGN > ASAN_RED_ZONE_SIZE, we embed left redzone into first ALIGN
> > +     bytes of allocated space.  */
> > +  align = MAX (align, ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
> > +
> > +  tree alloca_rz_mask = build_int_cst (size_type_node, redzone_mask);
> > +  tree redzone_size = build_int_cst (size_type_node, ASAN_RED_ZONE_SIZE);
> > +
> > +  /* misalign = size & (ASAN_RED_ZONE_SIZE - 1)
> > +     partial_size = ASAN_RED_ZONE_SIZE - misalign.  */
> > +  g = gimple_build_assign (make_ssa_name (size_type_node, NULL), BIT_AND_EXPR,
> > +			   old_size, alloca_rz_mask);
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  tree misalign = gimple_assign_lhs (g);
> > +  g = gimple_build_assign (make_ssa_name (size_type_node, NULL), MINUS_EXPR,
> > +			   redzone_size, misalign);
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  tree partial_size = gimple_assign_lhs (g);
> > +
> > +  /* padding = align + ASAN_RED_ZONE_SIZE;
> > +     additional_size = padding + partial_size.  */
> > +  tree padding = build_int_cst (size_type_node,
> > +				align / BITS_PER_UNIT + ASAN_RED_ZONE_SIZE);
> > +  g = gimple_build_assign (make_ssa_name (size_type_node), PLUS_EXPR,
> > +			   partial_size, padding);
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  tree additional_size = gimple_assign_lhs (g);
> > +
> > +  /* new_size = old_size + additional_size.  */
> > +  g = gimple_build_assign (make_ssa_name (size_type_node), PLUS_EXPR, old_size,
> > +			   additional_size);
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  tree new_size = gimple_assign_lhs (g);
> > +
> > +  /* Build new __builtin_alloca call:
> > +       new_alloca_with_rz = __builtin_alloca (new_size, align).  */
> > +  tree fn = builtin_decl_implicit (BUILT_IN_ALLOCA_WITH_ALIGN);
> > +  gg = gimple_build_call (fn, 2, new_size,
> > +			  build_int_cst (size_type_node, align));
> > +  tree new_alloca_with_rz = make_ssa_name (ptr_type, gg);
> > +  gimple_call_set_lhs (gg, new_alloca_with_rz);
> > +  gimple_seq_add_stmt_without_update (&seq, gg);
> > +
> > +  /* new_alloca = new_alloca_with_rz + align.  */
> > +  g = gimple_build_assign (make_ssa_name (ptr_type), POINTER_PLUS_EXPR,
> > +			   new_alloca_with_rz,
> > +			   build_int_cst (size_type_node,
> > +					  align / BITS_PER_UNIT));
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  tree new_alloca = gimple_assign_lhs (g);
> > +
> > +  /* Replace old alloca ptr with NEW_ALLOCA.  */
> > +  replace_call_with_value (&gsi, new_alloca);
> > +
> > +  /* Poison newly created alloca redzones:
> > +      __asan_alloca_poison (new_alloca, old_size).  */
> > +  fn = builtin_decl_implicit (BUILT_IN_ASAN_ALLOCA_POISON);
> > +  gg = gimple_build_call (fn, 2, new_alloca, old_size);
> > +  gimple_seq_add_stmt_without_update (&seq, gg);
> > +
> > +  /* Save new_alloca_with_rz value into last_alloca_addr to use it during
> > +     allocas unpoisoning.  */
> > +  g = gimple_build_assign (last_alloca_addr, NOP_EXPR, new_alloca_with_rz);
> > +  gimple_seq_add_stmt_without_update (&seq, g);
> > +  gsi_insert_seq_before (&gsi, seq, GSI_SAME_STMT);
> > +}
> > +
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

  reply	other threads:[~2017-06-16  7:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170517122413eucas1p12f3a6e4e478c7fc2fddf513d2e3ea199@eucas1p1.samsung.com>
2017-05-17 12:25 ` [RFC, PATCH][ASAN] Implement dynamic allocas/VLAs sanitization Maxim Ostapenko
2017-05-29  7:28   ` Yuri Gribov
2017-06-06  7:32     ` [PING^2][RFC, PATCH][ASAN] Implement dynamic allocas/VLAs sanitization.​ Maxim Ostapenko
2017-06-13 12:11       ` [PING^3][RFC, " Maxim Ostapenko
2017-06-13 13:15         ` Jakub Jelinek
2017-06-14 13:21           ` Maxim Ostapenko
2017-06-14 17:34             ` Jakub Jelinek
2017-06-16  7:34               ` Richard Biener [this message]
2017-07-08 18:48         ` Andreas Schwab
2017-07-10  7:46           ` Maxim Ostapenko
2017-07-11 13:52             ` Andreas Schwab
2017-07-11 14:25               ` Maxim Ostapenko
2017-07-11 14:57                 ` Andreas Schwab
2017-07-11 16:27                   ` Maxim Ostapenko
2017-07-12 16:58                     ` Andreas Schwab

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=alpine.LSU.2.20.1706160930240.22867@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=m.ostapenko@samsung.com \
    --cc=polacek@redhat.com \
    --cc=tetra2005@gmail.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 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).