Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: enable address sanitizer in Go #44853

Open
zhangfannie opened this issue Mar 8, 2021 · 49 comments
Open

runtime: enable address sanitizer in Go #44853

zhangfannie opened this issue Mar 8, 2021 · 49 comments

Comments

@zhangfannie
Copy link
Contributor

@zhangfannie zhangfannie commented Mar 8, 2021

The address sanitizer (Asan) is a memory error detector, it finds a number of memory access errors that can occur in C, such as out-of-bounds accesses to heap, stack and global objects, and use-after-free. In general, these issues do not occur in the pure Go code, unless people intentionally use the unsafe package. However, people can use cgo to pass memory back and forth between C and Go, which will cause memory access problems.

Please refer to the following cases.
In this case (case-1) https://play.golang.org/p/eE_8k4poelj, C passes Go an invalid pointer, causing the Go code to have use-after-free errors. In this case (case-2) https://play.golang.org/p/wtHjV-4xuiL, Go passes C a pointer, the C code has out-of-bounds access to heap objects errors. In this case (case-3) https://play.golang.org/p/rOyEo7I7vTY, Go passes C a pointer, the C code has out-of-bounds access to global objects errors.

Integrating Asan with Go would detect the above memory errors. So it is useful. In addition, Asan can help to detect some memory errors that MSan cannot. For example, use-after-free memory error case https://play.golang.org/p/eE_8k4poelj, MSan cannot detect writes on uninitialized memory, while ASan can.

And we can instrument ASan in exactly the same way as MSan. As with the -msan option, if we do not run with -asan option, it has no effect on code execution, if you use it, it may find some memory errors.

Although the above cases are not real world cases. However, on the other hand, when debugging a memory error access in a Go program that calls C code, it is really good to be able to use Asan to ensure that code is correct. Obviously, this will require more code to be maintained in the toolchain, but since almost all of the code is next to the existing MSan code, this is quite limited.

Besides, Arm has a hardware feature MTE (Memory Tagging Extension), it aims to further mitigate these memory safety bugs by enabling us to detect them with low overhead. If ASan will be proven to be useful, we may consider enabling MTE for ASan. In this way, ASan even be enabled in the production environment to help to detect memory errors with low overhead. I saw a blog that introduces enable MTE in Android to detect the most common classes of memory safety bugs. Please refer to the document https://security.googleblog.com/2019/08/adopting-arm-memory-tagging-extension.html.

Thank you.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Mar 8, 2021

I have updated the CLs for address sanitizer support, The implementation is divided into some smaller CLs 298610, 298611, 298612, 298613, 298614 for review. And with the current implementation, the -asan option can check for error memory access to heap objects. Thank you.

@oiooj oiooj changed the title proposal:enable address sanitizer in Go proposal: enable address sanitizer in Go Mar 8, 2021
@gopherbot gopherbot added this to the Proposal milestone Mar 8, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Mar 8, 2021
@AZ-X
Copy link

@AZ-X AZ-X commented Mar 13, 2021

I care about size of binary. Can you compare both size including small samples(<5M) and big samples(>10M)?

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Mar 15, 2021

@AZ-X If you run the go program without the -asan option, the size of binary will not change. Generally, we only enable the address sanitizer in the test environment to help detect memory access issues, so I think the size of binary is not important. Thank you.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Mar 19, 2021

@AZ-X Regarding your question, my answer above seems too one-sided. I wrote a test case to compare the size of binary, and the size of binary with -asan is almost 10% larger than that without -asan. Please refer to the following results.

func main() {
        var overall [][]int
        var m runtime.MemStats
        s := 2*1024*1024                 //  >10M big samples
        //s := 10*1024                     // <1M small samples
        for i := 0; i < 10; i++ {
                a := make([]int, 0, 10*s)
                overall = append(overall, a)
        }
        runtime.ReadMemStats(&m)
        fmt.Printf("Alloc = %v MB", bToMb(m.Alloc))
}
func bToMb(b uint64) uint64 {
        return b / 1024 / 1024
}

// the binay size:

  size           binary
2154616   big_asan               // build with -asan and big samples
1950161   big_noasan           // build without -asan and big samples  
2154624   small_asan            // build with -asan and small samples
1950161   small_noasan        // build without -asan and small samples
1940941   big_main              // build with master go and big samples
1940949   small_main           // build with master go and small samples

From the above result, the size of binary is bigger. But as I mentioned above, we don't recommend opening the asan option in a production environment. The factors to consider are not only size, but also performance. The good news is that ARM64 has a new feature of MTE, which is designed to detect error memory accesses with lower overhead. If ASan with MTE is enabled in Go in the future, the impact on performance and the size of the binary will be relatively small. Thank you.

@dvyukov
Copy link
Member

@dvyukov dvyukov commented Mar 19, 2021

If ASan with MTE is enabled in Go in the future

Do we need any support for this at all?
I would assume this will be done by just exporting some env var to enable MTE in the system malloc, e.g.:
https://sourceware.org/pipermail/libc-alpha/attachments/20200615/c8ef9e4e/attachment-0001.bin
https://patchwork.ozlabs.org/project/glibc/patch/8306e032-f980-a409-5239-74629e79d041@arm.com/
Or maybe in future it will be the default, so one doesn't need to do anything at all.

Though it can make sense to support MTE in Go runtime:
https://groups.google.com/g/golang-dev/c/ACKO07YeeW8/m/DX61CERlAwAJ

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Mar 19, 2021

Or maybe in future it will be the default, so one doesn't need to do anything at all.

In fact, we need to do something. Because Go has its own memory allocator, see https://golang.org/src/runtime/malloc.go, we may follow the implementaion in glic, refactor Go memory allcator (regarding the implementation details, I haven't done in-depth research. 🙂), setup memory tagging support if the hardware support it and if the user has requested it. Thank you.

@dvyukov
Copy link
Member

@dvyukov dvyukov commented Mar 19, 2021

Yes, that's what I mean by "support MTE in Go runtime". But we don't need anything related to asan (linking asan, asan hooks, etc)

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Mar 19, 2021

Yes, that's what I mean by "support MTE in Go runtime". But we don't need anything related to asan (linking asan, asan hooks, etc)

Yes, you are right. With MTE, all load and store instructions, except for with SP base register and immediate offset, do check tags. Here https://github.com/google/sanitizers/wiki/Stack-instrumentation-with-ARM-Memory-Tagging-Extension-(MTE) introduces how MTE works for stack. Thank you.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298610 mentions this issue: cmd/link: add -asan option

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298611 mentions this issue: cmd/compile: add -asan option

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298612 mentions this issue: cmd/go: add -asan option

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298613 mentions this issue: runtime, runtime/asan: add asan runtime support

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298614 mentions this issue: runtime, syscall: add calls to asan functions

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 26, 2021

Change https://golang.org/cl/298615 mentions this issue: cmd/dist: add asan tests in misc/cgo/testsanitizers package

@AZ-X
Copy link

@AZ-X AZ-X commented May 12, 2021

any updates?

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented May 13, 2021

any updates?

It has entered the code freeze for Go 1.17. 😟

@ianlancetaylor Any plans for it in 1.18? Thank you.

@andreybokhanko
Copy link
Contributor

@andreybokhanko andreybokhanko commented May 14, 2021

@AZ-X Regarding your question, my answer above seems too one-sided. I wrote a test case to compare the size of binary, and the size of binary with -asan is almost 10% larger than that without -asan. Please refer to the following results.

func main() {
        var overall [][]int
        var m runtime.MemStats
        s := 2*1024*1024                 //  >10M big samples
        //s := 10*1024                     // <1M small samples
        for i := 0; i < 10; i++ {
                a := make([]int, 0, 10*s)
                overall = append(overall, a)
        }
        runtime.ReadMemStats(&m)
        fmt.Printf("Alloc = %v MB", bToMb(m.Alloc))
}
func bToMb(b uint64) uint64 {
        return b / 1024 / 1024
}

// the binay size:

  size           binary
2154616   big_asan               // build with -asan and big samples
1950161   big_noasan           // build without -asan and big samples  
2154624   small_asan            // build with -asan and small samples
1950161   small_noasan        // build without -asan and small samples
1940941   big_main              // build with master go and big samples
1940949   small_main           // build with master go and small samples

From the above result, the size of binary is bigger. But as I mentioned above, we don't recommend opening the asan option in a production environment. The factors to consider are not only size, but also performance. The good news is that ARM64 has a new feature of MTE, which is designed to detect error memory accesses with lower overhead. If ASan with MTE is enabled in Go in the future, the impact on performance and the size of the binary will be relatively small. Thank you.

I assume all these measurements are done on ARM, right? What about x86?

Also, do you plan to implement first-class ASan support on x86-64? (Obviously, without MTE, as it's not available on x86)

Yours,
Andrey
===
Advanced Software Technology Lab
Huawei

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented May 17, 2021

I assume all these measurements are done on ARM, right? What about x86?

The size of binary with -asan is almost 11% larger than that without -asan. Please refer to the following results.

The binary size on x86-64.

      size                 binary
    1998048          big_asan
    1785270          big_noasan
    1785246          big_main
    1998048         small_asan
    1785270         small_noasan
    1785246         small_main

Also, do you plan to implement first-class ASan support on x86-64? (Obviously, without MTE, as it's not available on x86)

The current implementation also enables the ASan support on x86-64. Thank you.

@gopherbot
Copy link

@gopherbot gopherbot commented May 24, 2021

Change https://golang.org/cl/321715 mentions this issue: cmd/compile: enable Asan check for global variables

@gopherbot
Copy link

@gopherbot gopherbot commented May 24, 2021

Change https://golang.org/cl/321716 mentions this issue: cmd/dist: add asan tests for global objects in testsanitizers package

@ph1048
Copy link

@ph1048 ph1048 commented May 24, 2021

Hello!

What are your plans on supporting ASan for stack-based objects? The problem is that usage of unsafe.Pointer does not affect escape analysis, and there are lots of cases with potentially insecure dereference of unsafe.Pointer to stack objects. AFAIK go does not generate any stack canary code, so those vulnerabilities should be easily exploitable.
Simple example:
https://play.golang.org/p/5BLnDJtleF4
Here, due to misuse of unsafe.Pointer we have easy IP control.

Also, if you add MTE support, which runtime are you going to use, and will it be part of Go Asan implementation, or another feature?

Best wishes, Alex

@thepudds
Copy link

@thepudds thepudds commented May 24, 2021

For reference, there was some discussion of some different aspects of this proposal in this golang-dev thread:

https://groups.google.com/g/golang-dev/c/ACKO07YeeW8

@ph1048, FYI, there was some discussion there around stack objects, though perhaps @zhangfannie will have more to say here.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented May 27, 2021

Also, if you add MTE support, which runtime are you going to use, and will it be part of Go Asan implementation, or another feature?

@ph1048 Add MTE support is another feature, as @dvyukov commented above, we do not need to call any compiler-rt address sanitizer runtime functions. Thank you.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Jun 1, 2021

With the implementation of CL 321715 , ASan in Go can detect the error memory access to heap objects and global objects. For stack objects, as we discussed in the golang-dev mailing list https://groups.google.com/g/golang-dev/c/ACKO07YeeW8/m/B93kNorLBgAJ, we currently have no plans to add support for it. In this way, support ASan in Go is complete.

Welcome to review these patches. Thank you.

@andreybokhanko
Copy link
Contributor

@andreybokhanko andreybokhanko commented Jun 1, 2021

Hi @zhangfannie

With all respect, I find these two statements:

For stack objects, as we discussed in the golang-dev mailing list https://groups.google.com/g/golang-dev/c/ACKO07YeeW8/m/B93kNorLBgAJ, we currently have no plans to add support for it.

In this way, support ASan in Go is complete.

to be mutually contradictory.

Without stack objects being supported, ASan for Go is definitely not "complete". "ASan for heap and global objects" can be called as complete, sure -- but I still maintain that users shouldn't care on where their objects are allocated, especially giving that escape analysis can move objects from heap to stack easily.

As for plans to add support for stack objects, here is what @dvyukov wrote in the mailing list:

Either way, I would consider stack only after heap is implemented and
deployed. There is little point in planning/deciding re stack before
that.

I read this as "let's do heap objects first, then decide on stack objects support".

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Jun 2, 2021

@andreybokhanko

Thank you for correct my expression and "ASan for heap and global objects is complete" is more accurate.

As for plans to add support for stack objects, here is what I wrote in the mailing list:

To support for heap objects, we change the go memeory allocator and insert redzone around the heap objects. Support for stack objects also need to change the frame layout and insert redzone around the stack objects, this refactor may cause some problems.

One problem is the compatibility of abi. Go passes a value, it is also equal to pass the memory, we can use unsafe.Pointer to access the parameter adress and return adress. So far, I am not very clear about the definition of Go calling convention. I am not sure it is passing by value, or passing a memory region shared by caller and callee.

For example, in the following case, if ASan in Go wants to detect this error memory acces to stack objects, we need to insert redzone around the pass variables(a, b) and return variable (ret), which will break the current abi.

package main

import "fmt"
import "unsafe"

//go:noinline
func add(x int, y int) (ret int) {
	*(* int)(unsafe.Pointer((uintptr(unsafe.Pointer(&ret)) - 1*unsafe.Sizeof(ret)))) = 123    // Is it an error?
	*(* int)(unsafe.Pointer((uintptr(unsafe.Pointer(&ret)) - 2*unsafe.Sizeof(ret)))) = 543    // Is it an error?

	ret = x + y
	return
}

func main() {
	fmt.Println(add(42, 13))
}

At present, we do not have a good idea to support it. There should be 3 kinds of stack memory need to be considered, including local variables, argument variables and return variables.

If there is no clear calling conversion definition at the moment, maybe this can be a part of the discussion in regabi. @cherrymui

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 9, 2021

One thing I don't see in the CL series is tests. I would expect to see a CL adding some tests to misc/cgo/testsanitizers.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Sep 10, 2021

Note that this proposal has not yet been approved.

Sorry, I did not notice this, and I am not very clear about the approval process.

In addition, we had some discussions about this proposal in the golang-dev thread and you commented that it is reasonable (https://groups.google.com/g/golang-dev/c/ACKO07YeeW8). So I thought this proposal was accepted. 🙂

How can this proposal be approved? Thank you.

One thing I don't see in the CL series is tests. I would expect to see a CL adding some tests to misc/cgo/testsanitizers.

These two CLs https://go-review.googlesource.com/c/go/+/298615/13 and https://go-review.googlesource.com/c/go/+/321716/19 added some tests to misc/cgo/testsanitizers. Thank you.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Sep 10, 2021

The proposal process is described at https://golang.org/s/proposal.

Sorry for missing the tests.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Sep 13, 2021

Ok, I see. We are waiting for this proposal to be added to the Active column. Thank you.

@rsc
Copy link
Contributor

@rsc rsc commented Sep 22, 2021

Hello everyone,

In the thread above, there is some discussion about whether the CLs are implementing:

  1. Integration with the standard ASAN.
  2. Code using MTE with Go that doesn't call into the standard ASAN.

Which of these is it? Or is it

  1. Integration with the standard ASAN, and then also code using MTE for Go.

There is also some discussion about stack objects and whether they need additional checks. (I believe the state is they don't have checks in the pending CLs.)

In the past we have approached ASAN as something that C++ needs for its reads/writes, but as I understand it we've never instrumented Go's reads/writes, because Go has bounds checking and so on. Is this proposal to do more for Go's reads/writes generally?

@rsc rsc changed the title proposal: enable address sanitizer in Go proposal: runtime: enable address sanitizer in Go Sep 22, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Sep 22, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc rsc moved this from Incoming to Active in Proposals Sep 22, 2021
@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Sep 23, 2021

@rsc Thank you for the review.

In the thread above, there is some discussion about whether the CLs are implementing:

Our implementation only integrates with the standard ASAN(llvm/compiler-rt) and supports arm64 and amd64. In the long term, we'd like to use MTE. We did not do that. The main concern is its acceptance on supporting non-existing hardware feature.

There is also some discussion about stack objects and whether they need additional checks. (I believe the state is they don't have checks in the pending CLs.)

In fact, the CL 325629 sets conversion to unsafe.Pointer as an escaping operation to work around the stack objects check.

In the past we have approached ASAN as something that C++ needs for its reads/writes, but as I understand it we've never instrumented Go's reads/writes, because Go has bounds checking and so on. Is this proposal to do more for Go's reads/writes generally?

Yes, our implementation(CL 298611) inserts asan instrumentation for the c++ address sanitizer during SSA building, every memory reads/writes will be replaced by a call to asanread/asanwrite. With this implementation, in this case https://play.golang.org/p/eE_8k4poelj, C passes Go an invalid pointer, Go can detect this error memory access.

@zhangfannie
Copy link
Contributor Author

@zhangfannie zhangfannie commented Sep 24, 2021

@rsc These two patches(CL 298615 and CL 321716) have added some test cases, which can well demonstrate the role of asan option in Go. Thank you.

@rsc
Copy link
Contributor

@rsc rsc commented Oct 6, 2021

Thanks for the clarifications. This has now been added to the minutes.
Does anyone have any objections to adding ASAN support behind a -asan flag to go build?

@rsc
Copy link
Contributor

@rsc rsc commented Oct 13, 2021

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

@rsc rsc moved this from Active to Likely Accept in Proposals Oct 13, 2021
@rsc rsc moved this from Likely Accept to Accepted in Proposals Oct 20, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Oct 20, 2021

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc rsc changed the title proposal: runtime: enable address sanitizer in Go runtime: enable address sanitizer in Go Oct 20, 2021
@rsc rsc removed this from the Proposal milestone Oct 20, 2021
@rsc rsc added this to the Backlog milestone Oct 20, 2021
gopherbot pushed a commit that referenced this issue Oct 22, 2021
The -asan option causes the linker to link against the runtime/asan
package in order to use the C/C++ address sanitizer.

This CL passes tests but is not usable by itself.  The actual
runtime/asan package, and support for -asan in the go tool and the
compiler, and tests, are in separate CLs.

Updates #44853.

Change-Id: Ifc6046c1f75ba52777cbb3d937a4b66e91d5798d
Reviewed-on: https://go-review.googlesource.com/c/go/+/298610
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gopherbot pushed a commit that referenced this issue Oct 25, 2021
The -asan option causes the compiler to add instrumentation for the
C/C++ address sanitizer.  Every memory read/write will be replaced
by a call to asanread/asanwrite.

This CL also inserts asan instrumentation during SSA building.

This CL passes tests but is not usable by itself. The actual
implementation of asanread/asanwrite in the runtime package, and
support for -asan in the go tool and tests, will follow in subsequent
CLs.

Updates #44853.

Change-Id: Ia18c9c5d5c351857420d2f6835f0daec2ad31096
Reviewed-on: https://go-review.googlesource.com/c/go/+/298611
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gopherbot pushed a commit that referenced this issue Oct 26, 2021
The -asan option compiles Go code to use the address sanitizer.  This is
intended for use when linking with C/C++ code compiled with -fsanitize=address.
When memory blocks are passed back and forth between C/C++ and Go, code in
both languages will agree as to whether the memory is validly allocated or not,
and will report errors for any use of invalid memory.

Updates #44853.

Change-Id: I0209002ef795cc1c823daae557fb80c906158db3
Reviewed-on: https://go-review.googlesource.com/c/go/+/298612
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
gopherbot pushed a commit that referenced this issue Oct 26, 2021
These are the runtime support functions for letting Go code interoperate
with the C/C++ address sanitizer. Calls to asanread/asanwrite are now
inserted by the compiler with the -asan option.  Calls to
asanunpoison/asanpoison will be from other runtime functions in a
subsequent CL.

Updates #44853.

Change-Id: I9e8fc0ce937828bc7f4a8b6637453ddc3862c47b
Reviewed-on: https://go-review.googlesource.com/c/go/+/298613
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gopherbot pushed a commit that referenced this issue Nov 2, 2021
Add explicit address sanitizer instrumentation to the runtime and
syscall packages. The compiler does not instrument the runtime
package. It does instrument the syscall package, but we need to add
a couple of cases that it can't see.

Refer to the implementation of the asan malloc runtime library,
this patch also allocates extra memory as the redzone, around the
returned memory region, and marks the redzone as unaddressable to
detect the overflows or underflows.

Updates #44853.

Change-Id: I2753d1cc1296935a66bf521e31ce91e35fcdf798
Reviewed-on: https://go-review.googlesource.com/c/go/+/298614
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
gopherbot pushed a commit that referenced this issue Nov 2, 2021
Add asan tests to check the use of Go with -asan option.

Currenly, the address sanitizer in Go only checks for error
memory access to heap objects.

TODO: Enable check for error memory access to global objects.

Updates #44853.

Change-Id: I83579f229f117b5684a369fc8f365f4dea140648
Reviewed-on: https://go-review.googlesource.com/c/go/+/298615
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot
Copy link

@gopherbot gopherbot commented Dec 2, 2021

Change https://golang.org/cl/368834 mentions this issue: doc/go1.18: mention new -asan option

gopherbot pushed a commit that referenced this issue Dec 2, 2021
For #44853
For #47694

Change-Id: Ia76246218b1361d8bdf510bbfc5178c83cdd3eec
Reviewed-on: https://go-review.googlesource.com/c/go/+/368834
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Jan 4, 2022

Change https://golang.org/cl/375256 mentions this issue: runtime: add address sanitizer support for riscv64

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants