[Bug sanitizer/111736] New: Address sanitizer is not compatible with named address spaces

[Bug sanitizer/111736] New: Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

            Bug ID: 111736
           Summary: Address sanitizer is not compatible with named address
                    spaces
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ubizjak at gmail dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

From [1], gcc is doing a KASAN check on a percpu address (when percpu access is
implemented using named address spaces). This is not a "real" address, just an
offset from the segment register.

The testcase

--cut here--
int __seg_gs m;

int foo (void)
{
  return m;
}
--cut here--

does not show any special handling that would handle segment registers.

[1]
https://lore.kernel.org/lkml/CAHk-=wi6U-O1wdPOESuCE6QO2OaPu0hEzaig0uDOU4L5CREhug@mail.gmail.com/

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The "fix" is probably to not attempt to [K]ASAN any non-default address space
access?

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #2 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Looks that way — even though __seg_gs AS is a subset of the generic AS, the
compiler has no way to find out the base of __seg_gs.

We already skip registering TLS data with ASan:

__thread int x;

int foo (void)
{
  return x;
}

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[amonakov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #3 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Sorry, the second half of my comment is confusing. To clarify, ASan works fine
for TLS data (the compiler knows that TLS base is at fs:0; libsanitizer uses
some hacks to initialize shadow for TLS anyway, so it seems explicit
registration is not needed).

The difference is, &x produces an address in the generic address space by using
the knowledge that fs:0 stores the segment base. For __seg_{fs,gs} that can't
be done, and &m is the offset w.r.t segment base.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2023-12-05

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
testing patch

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:7e40497805c0831596334fe474112f991276e11b

commit r14-6184-g7e40497805c0831596334fe474112f991276e11b
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 14:00:43 2023 +0100

    sanitizer/111736 - skip ASAN for globals in alternate address-space

            PR sanitizer/111736
            * asan.cc (asan_protect_global): Do not protect globals
            in non-generic address-space.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed (for globals).

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to GCC Commits from comment #5)
> The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

Can this patch be backported to gcc-13 branch?

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to GCC Commits from comment #5)
> > The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
> 
> Can this patch be backported to gcc-13 branch?

Sure - I'll test/push it.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:06ffe577036fa58968960afc62e16349fa43d496

commit r13-8168-g06ffe577036fa58968960afc62e16349fa43d496
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 14:00:43 2023 +0100

    sanitizer/111736 - skip ASAN for globals in alternate address-space

            PR sanitizer/111736
            * asan.cc (asan_protect_global): Do not protect globals
            in non-generic address-space.

    (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.3

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
Huh, is this really fixed?

--cut here--
extern int __seg_gs m;

int foo (void)
{
  return m;
}

extern __thread int n;

int bar (void)
{
  return n;
}

extern int o;

int baz (void)
{
  return o;
}
--cut here--

gcc -O2 -fsanitize=address:


foo:
.LASANPC0:
.LFB0:
        .cfi_startproc
        movl    $m, %eax
        movq    %rax, %rdx
        andl    $7, %eax
        shrq    $3, %rdx
        addl    $3, %eax
        movzbl  2147450880(%rdx), %edx
        cmpb    %dl, %al
        jl      .L2
        testb   %dl, %dl
        jne     .L13
.L2:
        movl    %gs:m(%rip), %eax
        ret
.L13:
        pushq   %rax
        .cfi_def_cfa_offset 16
        movl    $m, %edi
        call    __asan_report_load4
        .cfi_endproc
.LFE0:
        .size   foo, .-foo
        .p2align 4
        .globl  bar
        .type   bar, @function

The memory access is still annotated with asan code.

I did test patched gcc by building a kernel with named address spaces, but I'm
not sure I did it correctly anymore - I was not able to boot recent -tip with
KASAN and enabled named address spaces.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #10)
> Huh, is this really fixed?

IMO, this patch is also needed:

--cut here--
diff --git a/gcc/asan.cc b/gcc/asan.cc
index cfe83106460..54dcc3a38db 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -2764,7 +2764,9 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
       && poly_int_tree_p (DECL_SIZE (inner), &decl_size)
       && known_subrange_p (bitpos, bitsize, 0, decl_size))
     {
-      if (VAR_P (inner) && DECL_THREAD_LOCAL_P (inner))
+      if (VAR_P (inner)
+         && (DECL_THREAD_LOCAL_P (inner)
+             || !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner)))))
        return;
       /* If we're not sanitizing globals and we can tell statically that this
         access is inside a global variable, then there's no point adding
--cut here--

But unfortunately, it doesn't result in bootable kernel.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #12 from Uroš Bizjak <ubizjak at gmail dot com> ---
P1, I would *really* like this PR to be fixed for gcc-14, the new linux kernel
support for named address spaces depend on this fix.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
The original testcase is fixed, appearantly slapping 'extern' on the int makes
it not effective.

Possibly better amend the

  if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
    return;

check though.  As indicated my fix fixed only VAR_DECL cases, there's
still pointer-based accesses (MEM_REF) to consider.  So possibly even
the following is necessary

diff --git a/gcc/asan.cc b/gcc/asan.cc
index 0fd7dd1f3ed..36f85757435 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -2747,7 +2747,8 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
       || maybe_ne (bitsize, size_in_bytes * BITS_PER_UNIT))
     return;

-  if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
+  if ((VAR_P (inner) && DECL_HARD_REGISTER (inner))
+      || !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner))))
     return;

   poly_int64 decl_size;

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
That also fixes

int foo (int __seg_gs *m)
{
  return *m;
}

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> The original testcase is fixed, appearantly slapping 'extern' on the int
> makes it not effective.
> 
> Possibly better amend the
> 
>   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
>     return;
> 
> check though.  As indicated my fix fixed only VAR_DECL cases, there's
> still pointer-based accesses (MEM_REF) to consider.  So possibly even
> the following is necessary
> 
> diff --git a/gcc/asan.cc b/gcc/asan.cc
> index 0fd7dd1f3ed..36f85757435 100644
> --- a/gcc/asan.cc
> +++ b/gcc/asan.cc
> @@ -2747,7 +2747,8 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
>        || maybe_ne (bitsize, size_in_bytes * BITS_PER_UNIT))
>      return;
>  
> -  if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> +  if ((VAR_P (inner) && DECL_HARD_REGISTER (inner))
> +      || !ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner))))
>      return;
>  
>    poly_int64 decl_size;

I'm testing this now - can you see if it is enough to fix the kernel usecase?

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #16 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Biener from comment #13)
> The original testcase is fixed, appearantly slapping 'extern' on the int
> makes it not effective.
> 
> Possibly better amend the
> 
>   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
>     return;
> 
> check though.  As indicated my fix fixed only VAR_DECL cases, there's
> still pointer-based accesses (MEM_REF) to consider.  So possibly even
> the following is necessary

I must admit that to create the patch from Comment #11 I just mindlessly
searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
ADDR_SPACE_GENERIC_P check.

However, ASAN should back off from annotating *any* gs: prefixed address. 

I'll test your patch from Comment #13 ASAP.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 21 Mar 2024, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
> 
> --- Comment #16 from Uro? Bizjak <ubizjak at gmail dot com> ---
> (In reply to Richard Biener from comment #13)
> > The original testcase is fixed, appearantly slapping 'extern' on the int
> > makes it not effective.
> > 
> > Possibly better amend the
> > 
> >   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> >     return;
> > 
> > check though.  As indicated my fix fixed only VAR_DECL cases, there's
> > still pointer-based accesses (MEM_REF) to consider.  So possibly even
> > the following is necessary
> 
> I must admit that to create the patch from Comment #11 I just mindlessly
> searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
> ADDR_SPACE_GENERIC_P check.

It might be that the DECL_THREAD_LOCAL_P handling is similarly broken
in that

int foo (int *p)
{
  return *p;
}

is instrumented even when p is a pointer to thread local storage?  But
maybe that works fine and it handled in the runtime.  But of course
the runtime can't handle non-generic address-spaces at all unless
we can convert all those addresses to ones in the generic address-space
(given suitable overlap of course).

> However, ASAN should back off from annotating *any* gs: prefixed address. 
> 
> I'll test your patch from Comment #13 ASAP.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #17)
> On Thu, 21 Mar 2024, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
> > 
> > --- Comment #16 from Uro? Bizjak <ubizjak at gmail dot com> ---
> > (In reply to Richard Biener from comment #13)
> > > The original testcase is fixed, appearantly slapping 'extern' on the int
> > > makes it not effective.
> > > 
> > > Possibly better amend the
> > > 
> > >   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> > >     return;
> > > 
> > > check though.  As indicated my fix fixed only VAR_DECL cases, there's
> > > still pointer-based accesses (MEM_REF) to consider.  So possibly even
> > > the following is necessary
> > 
> > I must admit that to create the patch from Comment #11 I just mindlessly
> > searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
> > ADDR_SPACE_GENERIC_P check.
> 
> It might be that the DECL_THREAD_LOCAL_P handling is similarly broken
> in that
> 
> int foo (int *p)
> {
>   return *p;
> }

No, that is not broken.  __thread/thread_local is something that applies solely
to variables.  If you take address of a TLS variable, the result is a normal
address space pointer even if TLS uses separate address spaces.  Pointer to TLS
var is e.g. on x86-64 load from %gs:0 with offset added to it, while load/store
of a TLS var is load/store from %gs:offset.
So, we actually wouldn't need to punt on DECL_THREAD_LOCAL_P variables, we can
just check their addresses.
We actually don't insert red zones in between the TLS var, so doing it wouldn't
make significant sense.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #19 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to Richard Biener from comment #13)
> > The original testcase is fixed, appearantly slapping 'extern' on the int
> > makes it not effective.
> > 
> > Possibly better amend the
> > 
> >   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> >     return;
> > 
> > check though.  As indicated my fix fixed only VAR_DECL cases, there's
> > still pointer-based accesses (MEM_REF) to consider.  So possibly even
> > the following is necessary
> 
> I must admit that to create the patch from Comment #11 I just mindlessly
> searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
> ADDR_SPACE_GENERIC_P check.
> 
> However, ASAN should back off from annotating *any* gs: prefixed address. 
> 
> I'll test your patch from Comment #13 ASAP.

Weee, it works!

Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel (entry_offset: 0x0000000000000000).
[    0.000000] Linux version 6.8.0-11485-ge1826833c3a9 (uros@localhost) (xgcc
(GCC) 14.0.1 20240321 (experimental) [master r14-9588-g415091f0909], GNU ld
version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC Thu Mar 21 09:44:30 CET 2024
...

I have used slightly different patch:

--cut here--
diff --git a/gcc/asan.cc b/gcc/asan.cc
index cfe83106460..026d079a4a1 100644
--- a/gcc/asan.cc
+++ b/gcc/asan.cc
@@ -2755,6 +2755,9 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
     return;

+  if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner))))
+    return;
+
   poly_int64 decl_size;
   if ((VAR_P (inner)
        || (TREE_CODE (inner) == RESULT_DECL
--cut here--

Hard registers and named address spaces really have nothing in common.

IMO, the fixes here should be applied to all release branches. Running KASAN
sanitized kernel with the named AS is the ultimate test for this PR.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Uroš Bizjak from comment #16)
> > (In reply to Richard Biener from comment #13)
> > > The original testcase is fixed, appearantly slapping 'extern' on the int
> > > makes it not effective.
> > > 
> > > Possibly better amend the
> > > 
> > >   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> > >     return;
> > > 
> > > check though.  As indicated my fix fixed only VAR_DECL cases, there's
> > > still pointer-based accesses (MEM_REF) to consider.  So possibly even
> > > the following is necessary
> > 
> > I must admit that to create the patch from Comment #11 I just mindlessly
> > searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
> > ADDR_SPACE_GENERIC_P check.
> > 
> > However, ASAN should back off from annotating *any* gs: prefixed address. 
> > 
> > I'll test your patch from Comment #13 ASAP.
> 
> Weee, it works!
> 
> Decompressing Linux... Parsing ELF... Performing relocations... done.
> Booting the kernel (entry_offset: 0x0000000000000000).
> [    0.000000] Linux version 6.8.0-11485-ge1826833c3a9 (uros@localhost)
> (xgcc (GCC) 14.0.1 20240321 (experimental) [master r14-9588-g415091f0909],
> GNU ld version 2.40-14.fc39) #1 SMP PREEMPT_DYNAMIC Thu Mar 21 09:44:30 CET
> 2024
> ...
> 
> I have used slightly different patch:
> 
> --cut here--
> diff --git a/gcc/asan.cc b/gcc/asan.cc
> index cfe83106460..026d079a4a1 100644
> --- a/gcc/asan.cc
> +++ b/gcc/asan.cc
> @@ -2755,6 +2755,9 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
>    if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
>      return;
>  
> +  if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (inner))))
> +    return;
> +

Agreed, this looks better.

Though, talking about address spaces, guess we also need to change ubsan.cc,
so that for targetm.addr_space.zero_address_valid (as) case it actually doesn't
try to
verify the pointers aren't NULL (it still should check alignment).

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #20)
> Though, talking about address spaces, guess we also need to change ubsan.cc,
> so that for targetm.addr_space.zero_address_valid (as) case it actually
> doesn't try to
> verify the pointers aren't NULL (it still should check alignment).

I'll handle that.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #22 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:134ef2a8cac1a5cc718739bd7d3b3472947c80d6

commit r14-9590-g134ef2a8cac1a5cc718739bd7d3b3472947c80d6
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Mar 21 08:30:39 2024 +0100

    tree-optimization/111736 - avoid address sanitizing of __seg_gs

    The following more thoroughly avoids address sanitizing accesses
    to non-generic address-spaces.

            PR tree-optimization/111736
            * asan.cc (instrument_derefs): Do not instrument accesses
            to non-generic address-spaces.

            * gcc.target/i386/pr111736.c: New testcase.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #23 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:6d5eb47849bcf9aecefacf7d7e4767750b1ec83b

commit r13-8476-g6d5eb47849bcf9aecefacf7d7e4767750b1ec83b
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Mar 21 08:30:39 2024 +0100

    tree-optimization/111736 - avoid address sanitizing of __seg_gs

    The following more thoroughly avoids address sanitizing accesses
    to non-generic address-spaces.

            PR tree-optimization/111736
            * asan.cc (instrument_derefs): Do not instrument accesses
            to non-generic address-spaces.

            * gcc.target/i386/pr111736.c: New testcase.

    (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57756&action=edit
gcc14-pr111736-ubsan.patch

Untested ubsan patch.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #25 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ddd4a3ca87410886b039cc225907b4f6e650082e

commit r14-9610-gddd4a3ca87410886b039cc225907b4f6e650082e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 22 09:23:44 2024 +0100

    ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

    On x86 and avr some address spaces allow 0 pointers (on avr actually
    even generic as, but libsanitizer isn't ported to it and
    I'm not convinced we should completely kill -fsanitize=null in that
    case).
    The following patch makes sure those aren't diagnosed for -fsanitize=null,
    though they are still sanitized for -fsanitize=alignment.

    2024-03-22  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
            SANITIZE_NULL instrumentation for non-generic address spaces
            for which targetm.addr_space.zero_address_valid (as) is true.

            * gcc.dg/ubsan/pr111736.c: New test.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #26 from Uroš Bizjak <ubizjak at gmail dot com> ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think it should.
E.g. for
int __seg_fs a;

void
foo (int __seg_fs *p)
{
  a = *p;
}
the instrumentation is
  _5 = __builtin_return_address (0);
  __builtin___tsan_func_entry (_5);
  __builtin___tsan_read4 (p_3(D));
  _1 = *p_3(D);
  __builtin___tsan_write4 (&a);
  a = _1;
  __builtin___tsan_func_exit (); [tail call]
but neither __tsan_read4 nor __tsan_write4 will know that the address they are
passed are not from the generic address space.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57807&action=edit
gcc14-pr111736-tsan.patch

Untested patch for tsan.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #29 from Uroš Bizjak <ubizjak at gmail dot com> ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.(In reply to Jakub Jelinek from comment
#28)
> Created attachment 57807 [details]
> gcc14-pr111736-tsan.patch
> 
> Untested patch for tsan.

Yes, this patch fixes the failure for linux kernel.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #30 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:471967ab8b4c49338ba77defbe24b06cc51c0093

commit r14-9667-g471967ab8b4c49338ba77defbe24b06cc51c0093
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 26 11:06:15 2024 +0100

    tsan: Don't instrument non-generic AS accesses [PR111736]

    Similar to the asan and ubsan changes, we shouldn't instrument non-generic
    address space accesses with tsan, because we just have library functions
    which take address of the objects as generic address space pointers, so
they
    can't handle anything else.

    2024-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * tsan.cc (instrument_expr): Punt on non-generic address space
            accesses.

            * gcc.dg/tsan/pr111736.c: New test.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #31 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:05de873353ab9e94cda2b9e9561a82ca4e061c3f

commit r13-8520-g05de873353ab9e94cda2b9e9561a82ca4e061c3f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 22 09:23:44 2024 +0100

    ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

    On x86 and avr some address spaces allow 0 pointers (on avr actually
    even generic as, but libsanitizer isn't ported to it and
    I'm not convinced we should completely kill -fsanitize=null in that
    case).
    The following patch makes sure those aren't diagnosed for -fsanitize=null,
    though they are still sanitized for -fsanitize=alignment.

    2024-03-22  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
            SANITIZE_NULL instrumentation for non-generic address spaces
            for which targetm.addr_space.zero_address_valid (as) is true.

            * gcc.dg/ubsan/pr111736.c: New test.

    (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #32 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:85b2b99e56b6f54b3feb530b2492955486e3d389

commit r13-8522-g85b2b99e56b6f54b3feb530b2492955486e3d389
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 26 11:06:15 2024 +0100

    tsan: Don't instrument non-generic AS accesses [PR111736]

    Similar to the asan and ubsan changes, we shouldn't instrument non-generic
    address space accesses with tsan, because we just have library functions
    which take address of the objects as generic address space pointers, so
they
    can't handle anything else.

    2024-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * tsan.cc (instrument_expr): Punt on non-generic address space
            accesses.

            * gcc.dg/tsan/pr111736.c: New test.

    (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #33 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:61d1962e7c3c32da6962d9cb20f6fd996501f3f2

commit r12-10387-g61d1962e7c3c32da6962d9cb20f6fd996501f3f2
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 14:00:43 2023 +0100

    sanitizer/111736 - skip ASAN for globals in alternate address-space

            PR sanitizer/111736
            * asan.cc (asan_protect_global): Do not protect globals
            in non-generic address-space.

    (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #34 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:e89b5ed62a5a06fb8918ffa1616f0f37c8d359c3

commit r12-10388-ge89b5ed62a5a06fb8918ffa1616f0f37c8d359c3
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Mar 21 08:30:39 2024 +0100

    tree-optimization/111736 - avoid address sanitizing of __seg_gs

    The following more thoroughly avoids address sanitizing accesses
    to non-generic address-spaces.

            PR tree-optimization/111736
            * asan.cc (instrument_derefs): Do not instrument accesses
            to non-generic address-spaces.

            * gcc.target/i386/pr111736.c: New testcase.

    (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #35 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:d6c62e4fb9a6d395599b7c78c831bace4bc7ff8f

commit r12-10389-gd6c62e4fb9a6d395599b7c78c831bace4bc7ff8f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 22 09:23:44 2024 +0100

    ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

    On x86 and avr some address spaces allow 0 pointers (on avr actually
    even generic as, but libsanitizer isn't ported to it and
    I'm not convinced we should completely kill -fsanitize=null in that
    case).
    The following patch makes sure those aren't diagnosed for -fsanitize=null,
    though they are still sanitized for -fsanitize=alignment.

    2024-03-22  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
            SANITIZE_NULL instrumentation for non-generic address spaces
            for which targetm.addr_space.zero_address_valid (as) is true.

            * gcc.dg/ubsan/pr111736.c: New test.

    (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #36 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:48fd1c5791b47717dcd4fa5615bc07cf54e964a7

commit r12-10390-g48fd1c5791b47717dcd4fa5615bc07cf54e964a7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 26 11:06:15 2024 +0100

    tsan: Don't instrument non-generic AS accesses [PR111736]

    Similar to the asan and ubsan changes, we shouldn't instrument non-generic
    address space accesses with tsan, because we just have library functions
    which take address of the objects as generic address space pointers, so
they
    can't handle anything else.

    2024-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR sanitizer/111736
            * tsan.cc (instrument_expr): Punt on non-generic address space
            accesses.

            * gcc.dg/tsan/pr111736.c: New test.

    (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #37 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:b86b523fb53f5ffb0e3f3236fc526a587944d9ea

commit r11-11349-gb86b523fb53f5ffb0e3f3236fc526a587944d9ea
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 14:00:43 2023 +0100

    sanitizer/111736 - skip ASAN for globals in alternate address-space

    gcc/ChangeLog:

            PR sanitizer/111736
            * asan.c (asan_protect_global): Do not protect globals
            in non-generic address-space.

    (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #38 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:b4e1aee01a2fa617cf74ab04cf0ab574761aaaea

commit r11-11350-gb4e1aee01a2fa617cf74ab04cf0ab574761aaaea
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Mar 21 08:30:39 2024 +0100

    tree-optimization/111736 - avoid address sanitizing of __seg_gs

    The following more thoroughly avoids address sanitizing accesses
    to non-generic address-spaces.

    gcc/ChangeLog:

            PR tree-optimization/111736
            * asan.c (instrument_derefs): Do not instrument accesses
            to non-generic address-spaces.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr111736.c: New testcase.

    (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #39 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:624c3bb9ff762f196852dc77233610d1cdf7d7be

commit r11-11351-g624c3bb9ff762f196852dc77233610d1cdf7d7be
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 22 09:23:44 2024 +0100

    ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736]

    On x86 and avr some address spaces allow 0 pointers (on avr actually
    even generic as, but libsanitizer isn't ported to it and
    I'm not convinced we should completely kill -fsanitize=null in that
    case).
    The following patch makes sure those aren't diagnosed for -fsanitize=null,
    though they are still sanitized for -fsanitize=alignment.

    2024-03-22  Jakub Jelinek  <jakub@redhat.com>

    gcc/ChangeLog:

            PR sanitizer/111736
            * ubsan.c (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
            SANITIZE_NULL instrumentation for non-generic address spaces
            for which targetm.addr_space.zero_address_valid (as) is true.

    gcc/testsuite/ChangeLog:

            * gcc.dg/ubsan/pr111736.c: New test.

    (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

--- Comment #40 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Uros Bizjak <uros@gcc.gnu.org>:

https://gcc.gnu.org/g:09910b6753427eeb3f6dded4fae3578851da7422

commit r11-11352-g09910b6753427eeb3f6dded4fae3578851da7422
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 26 11:06:15 2024 +0100

    tsan: Don't instrument non-generic AS accesses [PR111736]

    Similar to the asan and ubsan changes, we shouldn't instrument non-generic
    address space accesses with tsan, because we just have library functions
    which take address of the objects as generic address space pointers, so
they
    can't handle anything else.

    2024-03-26  Jakub Jelinek  <jakub@redhat.com>

    gcc/ChangeLog:

            PR sanitizer/111736
            * tsan.c (instrument_expr): Punt on non-generic address space
            accesses.

    gcc/testsuite/ChangeLog:

            * gcc.dg/tsan/pr111736.c: New test.

    (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |11.5
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #41 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed everywhere.