claudiu.zissulescu-iancule...@oracle.com writes:
> From: Indu Bhagat <indu.bha...@oracle.com>
>
> Add new command line option -fsanitize=memtag-stack with the following
> new params:
> --param memtag-instrument-alloca [0,1] (default 1) to use MTE insns
> for enabling dynamic checking of stack allocas.
>
> Along with the new SANITIZE_MEMTAG_STACK, define a SANITIZE_MEMTAG
> which will be set if any kind of memtag sanitizer is in effect (e.g.,
> later we may add -fsanitize=memtag-globals).  Add errors to convey
> that memtag sanitizer does not work with hwaddress and address
> sanitizers.  Also error out if memtag ISA extension is not enabled.
>
> MEMTAG sanitizer will use the HWASAN machinery, but with a few
> differences:
>   - The tags are always generated at runtime by the hardware, so
>     -fsanitize=memtag-stack enforces a --param hwasan-random-frame-tag=1
>
> Add documentation in gcc/doc/invoke.texi.
>
> gcc/
>       * builtins.def: Adjust the macro to include the new
>       SANTIZIE_MEMTAG_STACK.
>       * flag-types.h (enum sanitize_code): Add new enumerator for
>       SANITIZE_MEMTAG and SANITIZE_MEMTAG_STACK.
>       * opts.cc (finish_options): memtag-stack sanitizer conflicts with
>       hwaddress and address sanitizers.
>       (sanitizer_opts): Add new memtag-stack sanitizer.
>       (parse_sanitizer_options): memtag-stack sanitizer cannot recover.
>       * params.opt: Add new params for memtag-stack sanitizer.
>
> doc/
>       * invoke.texi: Update documentation.
>
> Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-iancule...@oracle.com>
> ---
>  gcc/builtins.def    |  1 +
>  gcc/doc/invoke.texi | 13 ++++++++++++-
>  gcc/flag-types.h    |  4 ++++
>  gcc/opts.cc         | 22 +++++++++++++++++++++-
>  gcc/params.opt      |  4 ++++
>  5 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index 4d311938ce8..ec984c6b7ce 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index 4d311938ce8..ec984c6b7ce 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> @@ -1308,6 +1308,24 @@ finish_options (struct gcc_options *opts, struct 
> gcc_options *opts_set,
>    report_conflicting_sanitizer_options (opts, loc, SANITIZE_USER_ADDRESS,
>                                       SANITIZE_KERNEL_ADDRESS);
> 
> +  /* Sanitizers using Memory-Tagging Extension conflict with HWASAN and
> +     ASAN.  */
> +  report_conflicting_sanitizer_options (opts, loc, SANITIZE_MEMTAG,
> +                                     SANITIZE_HWADDRESS);
> +  report_conflicting_sanitizer_options (opts, loc, SANITIZE_MEMTAG,
> +                                     SANITIZE_ADDRESS);
> +
> +   /* Memtag sanitizer implies HWASAN but with tags always generated by
> +      the hardware randomly.  */

Formatting nit: the /* ... */ block is indented by one column too many.

> +  if ((opts->x_flag_sanitize & SANITIZE_MEMTAG_STACK)
> +      && opts->x_param_hwasan_random_frame_tag == 0)
> +    {
> +       warning_at (loc, OPT_fsanitize_,
> +                "%<--param hwasan-random-frame-tag=0%> is ignored when "
> +                "%<-fsanitize=memtag-stack%> is present");
> +       opts->x_param_hwasan_random_frame_tag = 1;
> +    }
> +
>    /* Check error recovery for -fsanitize-recover option.  */
>    for (int i = 0; sanitizer_opts[i].name != NULL; ++i)
>      if ((opts->x_flag_sanitize_recover & sanitizer_opts[i].flag)
> @@ -2300,7 +2319,8 @@ parse_sanitizer_options (const char *p, location_t loc, 
> int scode,
>               else if (code == OPT_fsanitize_recover_)
>                 flags |= ~(SANITIZE_THREAD | SANITIZE_LEAK
>                            | SANITIZE_UNREACHABLE | SANITIZE_RETURN
> -                          | SANITIZE_SHADOW_CALL_STACK);
> +                          | SANITIZE_SHADOW_CALL_STACK
> +                          | SANITIZE_MEMTAG_STACK);

Could you explain this?  How is the -fsanitize-recover choice propagated
for MTE tagging?  For traditional santisers it affects the arguments
to the sanitizer library calls, but I was under the impression that
that wouldn't be the case for MTE.

Otherwise it looks good to me.

Thanks,
Richard

Reply via email to