An attacker can trick the Windows system verifier to use a poisoned set
of elliptic curve parameters for a trusted root, allowing it to generate
spoofed signatures. When this happens, the returned chain will present
the unmodified original root, so the actual signatures won't verify (as
they are invalid for the correct parameters). Simply double check them
as a safety measure and mitigation.
Windows users should still install the system security patch ASAP.
This is the same mitigation adopted by Chromium:
https://chromium-review.googlesource.com/c/chromium/src/+/1994434
Change-Id: I2c734f6fb2cb51d906c7fd77034318ffeeb3e146
Reviewed-on: https://go-review.googlesource.com/c/go/+/215905
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ryan Sleevi <sleevi@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Running the 'TestBuildForTvOS' test with CGO_CFLAGS set
with certain values would cause the test to fail. all.bash
would fail when CGO_CFLAGS was set to '-mmacosx-version-min=10.10'
because the --macosx-version-min flag is incompatible with tvOS.
The change guards against using an unintended flag in the unit test.
Updates #35459
Change-Id: Ifc43f3ebfb23d37aabeaac2ea9efae5b877991bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/215957
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In reviewing CL 215940, it took me a while to find the control
condition for the test, which was located in build_cache_trimpath.txt.
We could consolidate the two tests, but since they check for
regressions of separate issues (with separate root-causes), I think it
makes sense to keep them separate.
However, I would like the control condition to be present in the same
source file, so that we'll be more likely to update both cases if the
behavior of one of them is changed.
Updates #36566
Change-Id: Ic588f1dfb7977dd78d1d5ef61b9841e22bad82e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/216018
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
With the command below, I was able to reproduce failures within the
first 50 or so runs:
go test -c -o test && stress -p 32 ./test -test.run Script/test_regexp
When printing the full failure output, we'd see:
BenchmarkX
BenchmarkX: x_test.go:13: LOG: X running N=1
BenchmarkX/Y
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1
BenchmarkX/Y: x_test.go:15: LOG: Y running N=100
BenchmarkX/Y: x_test.go:15: LOG: Y running N=10000
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1000000
BenchmarkX/Y: x_test.go:15: LOG: Y running N=100000000
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1000000000
BenchmarkX/Y 1000000000 0.000050 ns/op
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1
BenchmarkX/Y: x_test.go:15: LOG: Y running N=30
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1207
BenchmarkX/Y: x_test.go:15: LOG: Y running N=120700
BenchmarkX/Y: x_test.go:15: LOG: Y running N=12070000
BenchmarkX/Y: x_test.go:15: LOG: Y running N=1000000000
BenchmarkX/Y 1000000000 0.000715 ns/op
In other words, the N values aren't required to be exact. It seems like
they are cut short if the machine is under stress. That's the exact
scenario we reproduce above, since I used -p=32 on my laptop with only 4
real CPU cores.
First, don't require each line to be present. Instead, use patterns
that span multiple lines, so that we can just match the first and last
N= lines.
Second, don't require the last N= lines to be exact; simply require
them to have a reasonably large number of digits.
Fixes#36664.
Change-Id: I7a9818f1a07099fa6482a26da2ac5cbea0f8ab30
Reviewed-on: https://go-review.googlesource.com/c/go/+/215578
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If a package has a module with a version, the package's directory is
replaced with the module path and version, followed by the package's
path within the module.
This is a follow up to CL 214945. We no longer check whether the
module has a directory (with -mod=vendor, it does not).
Updates #36566
Change-Id: I5bc952b13bc7b4659f58ee555bd6c6a087eb7792
Reviewed-on: https://go-review.googlesource.com/c/go/+/215940
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
While this instruction is not needed for the relocation (the lower immediate
can be patched directly into the JALR instruction), other code currently
depends on the jump sequence being 12 bytes (or three instructions) long.
Put the ADDI instruction back until these can be found and fixed.
Updates #27532
Change-Id: Idb73d716be8eb2eb796591b30f1ec4dc104f2bf8
Reviewed-on: https://go-review.googlesource.com/c/go/+/215840
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts commit e6c12c3d02.
Reason for revert: the assumption that a T-E of "gzip" implies
"chunked" seems incorrect. The RFC does state that one "MUST apply
chunked as the final transfer coding" but that should be interpreted to
mean that a "chunked" encoding must be listed as the last one, not that
one should be assumed to be there if not. This is confirmed by the
alternative option to chunking on the server side being to "terminate
the message by closing the connection".
The issue seems confirmed by the fact that the code in the body of
#29162 fails with the following error:
net/http: HTTP/1.x transport connection broken: http: failed to gunzip body: unexpected EOF
This late in the cycle, revert rather than fix, also because we don't
apparently have tests for the correct behavior.
Change-Id: I920ec928754cd8e96a06fb7ff8a53316c0f959e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/215757
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Unlike C's memmove, Go's memmove must be careful to do indivisible
writes of pointer values because it may be racing with the garbage
collector reading the heap.
We've had various bugs related to this over the years (#36101, #13160,
#12552). Indeed, memmove is a great target for optimization and it's
easy to forget the special requirements of Go's memmove.
The CL documents these (currently unwritten!) requirements. We're also
adding a test that should hopefully keep everyone honest going
forward, though it's hard to be sure we're hitting all cases of
memmove.
Change-Id: I2f59f8d8d6fb42d2f10006b55d605b5efd8ddc24
Reviewed-on: https://go-review.googlesource.com/c/go/+/213418
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The timers code used to have a problem: if code started and stopped a
lot of timers, as would happen with, for example, lots of calls to
context.WithTimeout, then it would steadily use memory holding timers
that had stopped but not been removed from the timer heap.
That problem was fixed by CL 214299, which would remove all deleted
timers whenever they got to be more than 1/4 of the total number of
timers on the heap.
The timers code had a different problem: if there were some idle P's,
the running P's would have lock contention trying to steal their timers.
That problem was fixed by CL 214185, which only acquired the timer lock
if the next timer was ready to run or there were some timers to adjust.
Unfortunately, CL 214185 partially undid 214299, in that we could now
accumulate an increasing number of deleted timers while there were no
timers ready to run. This CL restores the 214299 behavior, by checking
whether there are lots of deleted timers without acquiring the lock.
This is a performance issue to consider for the 1.14 release.
Change-Id: I13c980efdcc2a46eb84882750c39e3f7c5b2e7c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/215722
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
'go get all' was run in this test without -d. This caused some std
packages to be reinstalled if the test is run in a slightly different
configuration than make.bash was run. run.bash would fail in some
situations because of this. Nothing in the cmd/go tests should modify
installed std or cmd packages.
Updates #35459
Change-Id: Idd259a27d55502923b7fc54f361a77f0ac11eea2
Reviewed-on: https://go-review.googlesource.com/c/go/+/215721
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The FLW/FLD/FSW/FSD instructions can have immediates that exceed 12-bits and
therefore cannot be encoded in the RISCV instruction. Handle these as we do
for other load/store instructions. Also add test coverage for all load/store
instructions with large immediates.
Fixes compilation issue reported by Carlos Eduardo de Paula.
Updates #27532
Change-Id: Ifa62f19493b3acaba5a90ac31d2df209a3afea81
Reviewed-on: https://go-review.googlesource.com/c/go/+/215037
Reviewed-by: Carlos Eduardo de Paula <me@carlosedp.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ReverseProxy automatically sets the X-Forwarded-For header, if the request
already contains a X-Forwarded-For header, the value of the client IP is
appended to the existing header value.
This behavior isn't documented anywhere, and can lead to IP spoofing
security issues is the client is untrusted (the most common situation).
This PR documents this behavior.
For future versions, I proposed #36678 that implements a more secure
default behavior and adds support for other forwarded headers.
Change-Id: Ief14f5063caebfccb87714f54cffa927c714e5fd
GitHub-Last-Rev: fd0bd29a18
GitHub-Pull-Request: golang/go#36672
Reviewed-on: https://go-review.googlesource.com/c/go/+/215617
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There is a wrong offset when getting the results of a clock_gettime
syscall. Although the syscall will never be called in native ppc64x,
QEMU doesn't implement VDSO, so it will return wrong values.
Fixes#36592
Change-Id: Icf838075228dcdd62cf2c1279aa983e5993d66ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/215397
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
CL 214679 added a -race test which shouldn't be run when cgo is not
enabled.
Fixes the nocgo builder.
Change-Id: Iceddf802c4ef6c0de2c3a968e86342303d2d27d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/215477
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
R0 is not a thing in riscv64 assembly - use ZERO (rather than X0) since
the rest of this currently uses ABI names.
Updates #27532
Change-Id: I28fb68e9f80d05231a07c5921e7062777234e2c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/215437
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Based on riscv-go port.
Updates #27532
Change-Id: If522807a382130be3c8d40f4b4c1131d1de7c9e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/204632
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The point of *net.OpError is to add details to an underlying lower
level error. It makes no sense to have an OpError without an Err and
a nil *OpError.Err will cause *OpError.Error() method to panic.
Fixes#33007
Change-Id: If4fb2501e02dad110a095b73e18c47312ffa6015
Reviewed-on: https://go-review.googlesource.com/c/go/+/187677
Reviewed-by: Rob Pike <r@golang.org>
Based on riscv-go port.
Updates #27532
Change-Id: Ia329daa243db63ff334053b8807ea96b97ce3acf
Reviewed-on: https://go-review.googlesource.com/c/go/+/204631
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Based on riscv-go port.
Update #27532
Change-Id: I791924f71078fd8dfe9c2fc03a3f21a3bc673721
Reviewed-on: https://go-review.googlesource.com/c/go/+/204634
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
It's good to be explicit, as it's not necessarily obvious (and indeed
the behavior has changed recently with https://go-review.googlesource.com/c/go/+/214822)
without an associated doc comment change).
Change-Id: I99d6398bf15b404b1b1b196e712e926e363251e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/215217
Reviewed-by: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The previous value was "too bogus" and caused objdump to crash.
Updated infinite loop test results (only run if -args -f) in ssa/debug_test.go
Probably also fixes#36621 but that bug needs more info to tell for certain.
Fixes#36570
Change-Id: I51144641d25d559308a98d726d87806bd340cc5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/215297
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In CL 199821, we stopped setting the module directory for vendored
packages when -mod=vendor is used. This broke -trimpath, since we
replace the module directory with a string derived from the module
path and version. A comment in CL 202977 makes it clear that the
module directory should not be set.
With this change, -trimpath falls back to replacing the package
directory with the package path if the module directory is not set. We
also fall back to replacing the package directory if the module
version is not set to avoid adding a meaningless @ only for the main
module.
As a consequence of this change, file names in vendored packages will
not have module versions, so file names will be a little different
between -mod=mod and -mod=vendor.
Fixes#36566
Change-Id: I0e9cd76d36a2028a49d0b6697ea9a9b3140d7ff3
Reviewed-on: https://go-review.googlesource.com/c/go/+/214945
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
I noticed this leak while writing CL 214977.
Change-Id: I7566952b8e4bc58939d23435aea86576fc58ddca
Reviewed-on: https://go-review.googlesource.com/c/go/+/214978
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go 1.14 will drop support for macOS 10.10, see #23011
This reverts CL 155097
Updates #26475
Updates #29340
Change-Id: I64d0275141407313b73068436ee81d13eacc4c76
Reviewed-on: https://go-review.googlesource.com/c/go/+/214058
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The HTML linter 'tidy' reports:
go_spec.html:2556: Warning: unescaped & which should be written as &
go_spec.html:3293: Warning: unescaped & or unknown entity "&s1"
go_spec.html:3293: Warning: unescaped & or unknown entity "&a"
go_spec.html:3294: Warning: unescaped & or unknown entity "&s2"
go_spec.html:3294: Warning: unescaped & or unknown entity "&a"
go_spec.html:2045: Warning: trimming empty <p>
go_spec.html:4526: Warning: trimming empty <ul>
go_spec.html:4533: Warning: trimming empty <ul>
go_spec.html:4539: Warning: trimming empty <ul>
This CL fixes all but the <ul> ones, which I think should be fixed
but are defended by a comment.
Change-Id: I0ca88f5e80755024801877ab1298025ecf8f10c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/214457
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This reduces lock contention when only a few P's are running and
checking for whether they need to run timers on the sleeping P's.
Without this change the running P's would get lock contention
while looking at the sleeping P's timers. With this change a single
atomic load suffices to determine whether there are any ready timers.
Change-Id: Ie843782bd56df49867a01ecf19c47498ec827452
Reviewed-on: https://go-review.googlesource.com/c/go/+/214185
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, the scavenger is paced according to how long it takes to
scavenge one runtime page's worth of memory. However, this pacing
doesn't take into account the additional cost of actually using a
scavenged page. This operation, "sysUsed," is a counterpart to the
scavenging operation "sysUnused." On most systems this operation is a
no-op, but on some systems like Darwin and Windows we actually make a
syscall. Even on systems where it's a no-op, the cost is implicit: a
more expensive page fault when re-using the page.
On Darwin in particular the cost of "sysUnused" is fairly close to the
cost of "sysUsed", which skews the pacing to be too fast. A lot of
soon-to-be-allocated memory ends up scavenged, resulting in many more
expensive "sysUsed" operations, ultimately slowing down the application.
The way to fix this problem is to include the future cost of "sysUsed"
on a page in the scavenging cost. However, measuring the "sysUsed" cost
directly (like we do with "sysUnused") on most systems is infeasible
because we would have to measure the cost of the first access.
Instead, this change applies a multiplicative constant to the measured
scavenging time which is based on a per-system ratio of "sysUnused" to
"sysUsed" costs in the worst case (on systems where it's a no-op, we
measure the cost of the first access). This ultimately slows down the
scavenger to a more reasonable pace, limiting its impact on performance
but still retaining the memory footprint improvements from the previous
release.
Fixes#36507.
Change-Id: I050659cd8cdfa5a32f5cc0b56622716ea0fa5407
Reviewed-on: https://go-review.googlesource.com/c/go/+/214517
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This reverts CL 214437.
Does not fix the issue, and the test was wrong so it did not detect that it did not fix the issue.
Updates #36375
Change-Id: I6a4112035a1e90f4fdafed6fdf4ec9dfc718b571
Reviewed-on: https://go-review.googlesource.com/c/go/+/214601
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since Durations only span 290 years, they are not good for
manipulating very remote times. I bounced off this problem recently
while doing some astronomical calculations and it took me a while to
realize I could get a 64-bit seconds value from time.Time.Unix and
subtract two of them to evaluate the interval.
I thought it worth adding a sentence to make this clear. It didn't
occur to me for quite a while that "Unix time" spans a huge range in
the Go library.
Change-Id: I76c75dc951dfd6bcf86e8b0be3cfec518a3ecdee
Reviewed-on: https://go-review.googlesource.com/c/go/+/213977
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Fixes#36375
Change-Id: I407a1db23868880b83e73bc136d274659483fb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/214437
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change the type printer to take a map of types that we're currently
printing. When we happen upon a type that we're already in the middle
of printing, print a reference to it instead.
A reference to another type is built using the offset of the first
byte of that type's string representation in the result. To facilitate
that computation (and it's probably more efficient, regardless), we
print the type to a buffer as we go, and build the string at the end.
It would be nice to use string.Builder instead of bytes.Buffer, but
string.Builder wasn't around in Go 1.4, and we'd like to bootstrap
from that version.
Fixes#29312
Change-Id: I49d788c1fa20f770df7b2bae3b9979d990d54803
Reviewed-on: https://go-review.googlesource.com/c/go/+/214239
Reviewed-by: Robert Griesemer <gri@golang.org>
The comment contained a link that had a file name and ID that no longer existed, so change to the URL of the corresponding part of the latest page.
Change-Id: I74e0885aabf470facc39b84035f7a83fef9c6a8e
GitHub-Last-Rev: 5681c84d9f
GitHub-Pull-Request: golang/go#36514
Reviewed-on: https://go-review.googlesource.com/c/go/+/214181
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Whenever more than 1/4 of the timers on a P's heap are deleted,
remove them from the heap.
Change-Id: Iff63ed3d04e6f33ffc5c834f77f645c52c007e52
Reviewed-on: https://go-review.googlesource.com/c/go/+/214299
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
