public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Alexander Ivchenko <aivchenk@gmail.com>
Cc: marxin@gcc.gnu.org, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [CHKP] Fix for PR79990
Date: Thu, 23 Mar 2017 20:34:00 -0000	[thread overview]
Message-ID: <CAMbmDYb79XYn1oqP1qjz=_JFrXd8q=DqtEwTv3RdwWyTjwg30Q@mail.gmail.com> (raw)
In-Reply-To: <CACysShgnUuetyR-7wAqh6wusBz67k-iVu6VGHzEzVvRvS2QW8Q@mail.gmail.com>

2017-03-23 17:18 GMT+03:00 Alexander Ivchenko <aivchenk@gmail.com>:
> Hi,
>
> The patch below attempts to fix the PR. I checked that it did not
> break any of mpx.exp tests, but I did not run the full testing yet.
> Would like to know whether this approach is generally correct or not.
>
> The issue is that we have the hard reg vector variable:
>
> typedef int U __attribute__ ((vector_size (16)));
> register U u asm("xmm0");
>
> and chkp tries to instrument access to it:
>
> return u[i];
>
> by doing that:
>
> __bound_tmp.0_4 = __builtin_ia32_bndmk (&u, 16);
>
> However, you cannot take an address of a register variable (in fact if
> you do that, the compiler will give you "address of register variable
> ‘u’ requested" error), so expand, sensibly, gives an ICE on on &u
> here. I believe that if there is no pointers, pointer bounds checker
> shouldn't get involved into that business. What do you think?

Hi!

I think with this patch I can call foo with any index and thus access
some random stack slot. The first thing we should answer is 'do we
want to catch array index overflows in such cases'? If we want to (and
this looks reasonable thing to do because it prevents invalid memory
accesses) then this patch doesn't resolve the problem.

I'm not sure it can affect the patch, but please consider more complex
cases. E.g.:

typedef int v8 __attribute__ ((vector_size(8)));

struct U {
  v8 a;
  v8 b;
};

int
foo (int i)
{
  register struct U u asm ("xmm0");
  return u.b[i];
}

One way to catch overflow in such cases might be to use some fake
pointer value (e.g. 0) for such not addressible variable. This fake value
would be used as base for memory access and as lower bound. I don't
see other cases except array_ref overflow check where such value
might be used. So this fake value will not be passed somewhere and
will not be stored to Bounds Table.

Thanks,
Ilya

>
>
>
>
> diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
> index 75caf83..e39ec9a 100644
> --- a/gcc/tree-chkp.c
> +++ b/gcc/tree-chkp.c
> @@ -3383,6 +3383,7 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
>    tree comp_to_narrow = NULL_TREE;
>    tree last_comp = NULL_TREE;
>    bool array_ref_found = false;
> +  bool is_register_var = false;
>    tree *nodes;
>    tree var;
>    int len;
> @@ -3440,6 +3441,9 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
>                   || TREE_CODE (var) == STRING_CST
>                   || TREE_CODE (var) == SSA_NAME);
>
> +      if (VAR_P (var) && DECL_HARD_REGISTER (var))
> +       is_register_var = true;
> +
>        *ptr = chkp_build_addr_expr (var);
>      }
>
> @@ -3455,7 +3459,11 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
>
>        if (TREE_CODE (var) == ARRAY_REF)
>         {
> -         *safe = false;
> +         // Mark it as unsafe, unless the array being accessed
> +         // has been explicitly placed on a register: in this
> +         // case we cannot take a pointer of this variable,
> +         // so we don't instrument the access.
> +         *safe = is_register_var;
>           array_ref_found = true;
>           if (flag_chkp_narrow_bounds
>               && !flag_chkp_narrow_to_innermost_arrray
> @@ -4001,6 +4009,19 @@ chkp_process_stmt (gimple_stmt_iterator *iter, tree node,
>         bool bitfield;
>         tree elt;
>
> +       {
> +         // We don't instrument accesses to arrays that
> +         // are explicitely assigned to hard registers.
> +         HOST_WIDE_INT bitsize, bitpos;
> +         tree base, offset;
> +         machine_mode mode;
> +         int unsignedp, reversep, volatilep = 0;
> +         base = get_inner_reference (node, &bitsize, &bitpos, &offset, &mode,
> +                                     &unsignedp, &reversep, &volatilep);
> +         if (VAR_P (base) && DECL_HARD_REGISTER (base))
> +           safe = true;
> +       }
> +
>         if (safe)
>           {
>             /* We are not going to generate any checks, so do not
>
> diff --git a/gcc/testsuite/gcc.target/i386/mpx/pr79990.c
> b/gcc/testsuite/gcc.target/i386/mpx/pr79990.c
> new file mode 100644
> index 0000000..a27734d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/mpx/pr79990.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
> +
> +typedef int U __attribute__ ((vector_size (16)));
> +
> +int
> +foo (int i)
> +{
> +#if __SSE2__
> +  register
> +#endif
> +    U u
> +#if __SSE2__
> +      asm ("xmm0")
> +#endif
> +      ;
> +  return u[i];
> +}
>
> regards,
> Alexander

  reply	other threads:[~2017-03-23 19:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 14:19 Alexander Ivchenko
2017-03-23 20:34 ` Ilya Enkovich [this message]
2017-04-02 20:53   ` Alexander Ivchenko
2017-04-10 21:22     ` Ilya Enkovich
2017-04-19 16:56       ` Alexander Ivchenko
     [not found]         ` <CAMbmDYZ+DDk-=hHzg-Qogawdee2R7XzGhEokbcXA5NhgiYs4ww@mail.gmail.com>
2017-04-20  9:54           ` Alexander Ivchenko
2017-04-20 17:46             ` Ilya Enkovich
2017-04-21 18:31               ` Alexander Ivchenko
2017-05-09 13:33                 ` Alexander Ivchenko
2017-05-10 17:20                   ` Ilya Enkovich
2017-06-08 19:45                   ` [PATCH] Fix mpx testcases (Re: [CHKP] Fix for PR79990) Jakub Jelinek
2017-06-08 20:02                     ` Ilya Enkovich

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='CAMbmDYb79XYn1oqP1qjz=_JFrXd8q=DqtEwTv3RdwWyTjwg30Q@mail.gmail.com' \
    --to=enkovich.gnu@gmail.com \
    --cc=aivchenk@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=marxin@gcc.gnu.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 read-only IMAP folder(s) and NNTP newsgroup(s).