[This is a (manual) backport of CL 527415 to Go 1.20.]
Currently, linking a Go c-shared object with C code using Apple's
new linker, it fails with
% cc a.c go.so
ld: segment '__DWARF' filesize exceeds vmsize in 'go.so'
Apple's new linker has more checks for unmapped segments. It is
very hard to make it accept a Mach-O shared object with an
additional DWARF segment.
We may want to stop combinding DWARF into the shared object (see
also #62577). For now, disable DWARF by default in c-shared mode
on darwin.
Updates #61229.
For #62597.
Change-Id: I313349f71296d6d7025db28469593825ce9f1866
Reviewed-on: https://go-review.googlesource.com/c/go/+/527819
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
There are some bugs in Apple's new linker that probably will not
be fixed when Xcode 15 is released (some time soon). We fix/work
around them but it is too much to backport them all. Force old
Apple linker to work around.
Updates #61229.
For #62597.
Change-Id: Ia5941918e882b22b4dbc41c74764d19d413d0b56
Reviewed-on: https://go-review.googlesource.com/c/go/+/527818
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The HTML specification has incredibly complex rules for how to handle
"<!--", "<script", and "</script" when they appear within literals in
the script context. Rather than attempting to apply these restrictions
(which require a significantly more complex state machine) we apply
the workaround suggested in section 4.12.1.3 of the HTML specification [1].
More precisely, when "<!--", "<script", and "</script" appear within
literals (strings and regular expressions, ignoring comments since we
already elide their content) we replace the "<" with "\x3C". This avoids
the unintuitive behavior that using these tags within literals can cause,
by simply preventing the rendered content from triggering it. This may
break some correct usages of these tags, but on balance is more likely
to prevent XSS attacks where users are unknowingly either closing or not
closing the script blocks where they think they are.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for
reporting this issue.
Fixes#62197Fixes#62397
Fixes CVE-2023-39319
[1] https://html.spec.whatwg.org/#restrictions-for-contents-of-script-elements
Change-Id: Iab57b0532694827e3eddf57a7497ba1fab1746dc
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976594
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2014621
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/526099
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
For aggregate-typed arguments passed to a call, expandCalls
decomposed them into parts in the same block where the value
was created. This is not necessarily the call block, and in
the case where stores are involved, can change the memory
leaving that block, and getting that right is problematic.
Instead, do all the expanding in the same block as the call,
which avoids the problems of (1) not being able to reorder
loads/stores across a block boundary to conform to memory
order and (2) (incorrectly, not) exposing the new memory to
consumers in other blocks. Putting it all in the same block
as the call allows reordering, and the call creates its own
new memory (which is already dealt with correctly).
Fixes#62056.
Updates #61992.
Change-Id: Icc7918f0d2dd3c480cc7f496cdcd78edeca7f297
Reviewed-on: https://go-review.googlesource.com/c/go/+/519276
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit e72ecc6a6b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/520059
On Darwin (and assume also on iOS but not sure), notetsleepg
cannot be called in a signal-handling context. Avoid this
by disabling block reads on Darwin.
An alternate approach was to add "sigNote" with a pipe-based
implementation on Darwin, but that ultimately would have required
at least one more linkname between runtime and syscall to avoid
racing with fork and opening the pipe, so, not.
Fixes#62018.
Updates #61768.
Change-Id: I0e8dd4abf9a606a3ff73fc37c3bd75f55924e07e
Reviewed-on: https://go-review.googlesource.com/c/go/+/518836
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit c6ee8e31e3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/518677
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Austin Clements <austin@google.com>
We do not index std as a whole module ever.
When working in the main Go repo, files in package change often,
so we don't want to pay the cost of reindexing all of std when what
we really need is just to reindex strings. Per-package indexing
works better for that case.
When using a released Go toolchain, we don't have to worry about
the whole module changing, but if we switch to whole-module indexing
at that point, we have the potential for bugs that only happen in
released toolchains. Probably not worth the risk.
For similar reasons, we don't index the current work module as
a whole module (individual packages are changing), so we use the heuristic
that we only do whole-module indexing in the module cache.
The new toolchain modules live in the module cache, though, and
our heuristic was causing whole-module indexing for them.
As predicted, enabling whole-module indexing for std when it's
completely untested does in fact lead to bugs (a very minor one).
This CL turns off whole-module indexing for std even when it is
in the module cache, to bring toolchain module behavior back in
line with the other ways to run toolchains.
Updates #57001.
For #61873.
Change-Id: I5012dc713f566846eb4b2848facc7f75bc956eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/504119
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
(cherry picked from commit a7b1793701)
Reviewed-on: https://go-review.googlesource.com/c/go/+/518415
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Historically, the Transport has silently truncated invalid
Host headers at the first '/' or ' ' character. CL 506996 changed
this behavior to reject invalid Host headers entirely.
Unfortunately, Docker appears to rely on the previous behavior.
When sending a HTTP/1 request with an invalid Host, send an empty
Host header. This is safer than truncation: If you care about the
Host, then you should get the one you set; if you don't care,
then an empty Host should be fine.
Continue to fully validate Host headers sent to a proxy,
since proxies generally can't productively forward requests
without a Host.
For #60374Fixes#61431Fixes#61826
Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/511155
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit b9153f6ef3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/518756
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
With #60078 accepted, we expect Go 1.22 will have different
for loop semantics than Go 1.20 did. Once Go 1.22 is released,
Go 1.20 will be unsupported, but add a check anyway, just to
help catch some mistakes and usage of old Go toolchains
beyond their end-of-support.
Note that Go 1.20 can keep being used indefinitely with pre-Go 1.22 code.
This change only makes it refuse to build code that says it needs
Go 1.22 semantics, because Go 1.20 does not provide those.
For #60078.
Change-Id: I75118d6fbd0cc08a6bc309aca54c389a255ba7dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/518675
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Verify that the Host header we send is valid.
Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops"
adding an X-Evil header to HTTP/1 requests.
Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to
header injection in the way HTTP/1 is, but x/net/http2 doesn't validate
the header and will go into a retry loop when the server rejects it.
CL 506995 adds the necessary validation to x/net/http2.
For #60374Fixes#61076
For CVE-2023-29406
Change-Id: I05cb6866a9bead043101954dfded199258c6dd04
Reviewed-on: https://go-review.googlesource.com/c/go/+/506996
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit 499458f7ca)
Reviewed-on: https://go-review.googlesource.com/c/go/+/507357
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.
A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.
For #60934Fixes#60949
Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 48dbb6227a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505676
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Due to the semantics of roots, a root store may contain two valid roots
that have the same subject (but different SPKIs) at the asme time. As
such in testVerify it is possible that when we verify a certificate we
may get two chains that has the same stringified representation.
Rather than doing something fancy to include keys (which is just overly
complicated), tolerate multiple matches.
Updates #60925Fixes#60947
Change-Id: I5f51f7635801762865a536bcb20ec75f217a36ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/505035
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 20313660f5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505275
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Heschi Kreinick <heschi@google.com>
This change addresses a `checkdead` panic caused by a race condition between
`sysmon->startm` and `checkdead` callers, due to prematurely releasing the
scheduler lock. The solution involves allowing a `startm` caller to acquire the
scheduler lock and call `startm` in this context. A new `lockheld` bool
argument is added to `startm`, which manages all lock and unlock calls within
the function. The`startIdle` function variable in `injectglist` is updated to
call `startm` with the lock held, ensuring proper lock handling in this
specific case. This refined lock handling resolves the observed race condition
issue.
For #59600.
Fixes#60760.
Change-Id: I11663a15536c10c773fc2fde291d959099aa71be
Reviewed-on: https://go-review.googlesource.com/c/go/+/487316
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
(cherry picked from commit ff059add10)
Reviewed-on: https://go-review.googlesource.com/c/go/+/504395
Reviewed-by: Lucien Coffe <lucien.coffe@botify.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Note: This CL is cherry-picked from CL 486816 omitting the changes
in sys_windows_386.s, which don't apply to go1.20 release branch
because windows/386 started using the TEB TLS slot in go1.21 (CL 454675).
The Go runtime allocates the TLS slot in the TEB TLS slots instead of
using the TEB arbitrary pointer. See CL 431775 for more context.
The problem is that the TEB TLS slots array only has capacity for 64
indices, allocating more requires some complex logic that we don't
support yet.
Although the Go runtime only allocates one index, a Go DLL can be
loaded in a process with more than 64 TLS slots allocated,
in which case it abort.
This CL avoids aborting by falling back to the older behavior, that
is to use the TEB arbitrary pointer.
Fixes#60535
Updates #59213
Change-Id: I39c73286fe2da95aa9c5ec5657ee0979ecbec533
Reviewed-on: https://go-review.googlesource.com/c/go/+/486816
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 715d53c090)
Reviewed-on: https://go-review.googlesource.com/c/go/+/504475
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
In racecallatomic, we do a load before calling into TSAN, so if
the address is invalid we fault on the Go stack. We currently use
a 8-byte load instruction, regardless of the data size that the
atomic operation is performed on. So if, say, we are doing a
LoadUint32 at an address that is the last 4 bytes of a memory
mapping, we may fault unexpectedly. Do a 1-byte load instead.
(Ideally we should do a load with the right size, so we fault
correctly if we're given an unaligned address for a wide load
across a page boundary. Leave that for another CL.)
Fix AMD64, ARM64, and PPC64. The code already uses 1-byte load
on S390X.
Fixes#60845.
Updates #60825.
Change-Id: I3dee93eb08ba180c85e86a9d2e71b5b520e8dcf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/503937
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 1a7709d6af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/503976
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Austin Clements <austin@google.com>
We parse mail messages using net/textproto. For #53188, we tightened
up the bytes permitted by net/textproto to match RFC 7230.
However, this package uses RFC 5322 which is more permissive.
Restore the permisiveness we used to have, so that older code
continues to work.
For #58862
For #60332Fixes#60874Fixes#60875
Change-Id: I5437f5e18a756f6ca61c13c4d8ba727be73eff9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/504881
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
The unused analyzer handles dot imports now, so a few tests
have picked up vet errors. This CL errors like:
context/x_test.go:524:47: result of context.WithValue call not used
This is a manual cherry-pick of CL 493598.
Updates #60058Fixes#60927
Change-Id: I92906ef7967e14a85fa974e6307fd689e3ff3dba
Reviewed-on: https://go-review.googlesource.com/c/go/+/504977
Auto-Submit: Heschi Kreinick <heschi@google.com>
TryBot-Bypass: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Fix two long tests that fail in the builders we're trying out:
- TestQueryImport was failing with:
open /nonexist-gopath/pkg/sumdb/sum.golang.org/latest: no such file or directory
which eventually turns out to be because it couldn't create
/nonexist-gopath because it wasn't running as root. The test already
uses a temporary GOPATH, but missed overriding a configuration
variable set at init time.
- test_flags fails if the working directory has /x/ in it, which it now
happens to.
Change-Id: Ideef0f318157b42987539e3a20f9fba6a3d3bdd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/480255
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 4526fa790e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/504975
Auto-Submit: Heschi Kreinick <heschi@google.com>
types2 have already errored about any spec-required overflows, and
division by zero. CL 469595 unintentionally fixed typecheck not to error
about overflows, but zero division is still be checked during tcArith.
This causes unsafe operations with variable size failed to compile,
instead of raising runtime error.
This CL also making change to typecheck.EvalConst, to stop evaluating
literal shifts or binary operators where {over,under}flows can happen.
For go1.21, typecheck.EvalConst is removed entirely, but that change is
too large to backport.
See discussion in CL 501735 for more details.
Fixes#60675
Change-Id: I7bea2821099556835c920713397f7c5d8a4025ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/501735
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/503855
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
We don't normally keep explicit requirements for test dependencies of
packages loaded from other modules when the required version is
already the selected version in the module graph. However, in some
cases we may need to keep an explicit requirement in order to make use
of lazy module loading to disambiguate an otherwise-ambiguous import.
Note that there is no Go version guard for this change: in the cases
where the behavior of 'go mod tidy' has changed, previous versions of
Go would produce go.mod files that break successive calls to
'go mod tidy'. Given that, I suspect that any existing user in the
wild affected by this bug either already has a workaround in place
using redundant import statements (in which case the change does not
affect them) or is running 'go mod tidy -e' to force past the error
(in which case a change in behavior to a non-error should not be
surprising).
Updates #60313.
Fixes#60352.
Change-Id: Idf294f72cbe3904b871290d79e4493595a0c7bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/496635
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 2ed6a54a39)
Reviewed-on: https://go-review.googlesource.com/c/go/+/499635
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
The go parser previously checked for invalid import paths, go/build,
seeing the parse error would put files with invalid import paths into
InvalidGoFiles. golang.org/cl/424855 removed that check from the
parser, which meant files with invalid import paths not have any parse
errors on them and not be put into InvalidGoFiles. Do a check for
invalid import paths in go/build soon after parsing so we can make
sure files with invalid import paths go into InvalidGoFiles.
This fixes an issue where the Go command assumed that if a file wasn't
invalid it had non empty import paths, leading to a panic.
Fixes#60754
Updates #60230
Updates #60686
Change-Id: I33c1dc9304649536834939cef7c689940236ee20
Reviewed-on: https://go-review.googlesource.com/c/go/+/502615
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
(cherry picked from commit 962753b015)
Reviewed-on: https://go-review.googlesource.com/c/go/+/502697
This updates the logic from CL 489075 to avoid trying to save extra
sums if they aren't already expected to be present
and cfg.BuildMod != "mod" (as in the case of "go list -m -u all" with
a go.mod file that specifies go < 1.21).
Fixes#60698.
Updates #60667.
Updates #56222.
Change-Id: Ied6ed3e80a62f9cd9a328b43a415a42d14481056
Reviewed-on: https://go-review.googlesource.com/c/go/+/502016
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
