Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/golang/go. Pull mirroring updated .
  1. Aug 01, 2022
  2. Jul 29, 2022
  3. Jul 26, 2022
  4. Jul 25, 2022
  5. Jul 22, 2022
    • Cherry Mui's avatar
      [release-branch.go1.17] runtime: use saved LR when unwinding through morestack · c25b12fb
      Cherry Mui authored
      On LR machine, consider F calling G calling H, which grows stack.
      The stack looks like
      ...
      G's frame:
      	... locals ...
      	saved LR = return PC in F  <- SP points here at morestack
      H's frame (to be created)
      
      At morestack, we save
      	gp.sched.pc = H's morestack call
      	gp.sched.sp = H's entry SP (the arrow above)
      	gp.sched.lr = return PC in G
      
      Currently, when unwinding through morestack (if _TraceJumpStack
      is set), we switch PC and SP but not LR. We then have
      	frame.pc = H's morestack call
      	frame.sp = H's entry SP (the arrow above)
      As LR is not set, we load it from stack at *sp, so
      	frame.lr = return PC in F
      As the SP hasn't decremented at the morestack call,
      	frame.fp = frame.sp = H's entry SP
      
      Unwinding a frame, we have
      	frame.pc = old frame.lr = return PC in F
      	frame.sp = old frame.fp = H's entry SP a.k.a. G's SP
      The PC and SP don't match. The unwinding will go off if F and G
      have different frame sizes.
      
      Fix this by preserving the LR when switching stack.
      
      Also add code to detect infinite loop in unwinding.
      
      TODO: add some test. I can reproduce the infinite loop (or throw
      with added check) but the frequency is low.
      
      Fixes #53111.
      Updates #52116.
      
      Change-Id: I6e1294f1c6e55f664c962767a1cf6c466a0c0eff
      Reviewed-on: https://go-review.googlesource.com/c/go/+/400575
      
      
      TryBot-Result: Gopher Robot <gobot@golang.org>
      Run-TryBot: Cherry Mui <cherryyz@google.com>
      Reviewed-by: default avatarEric Fang <eric.fang@arm.com>
      Reviewed-by: default avatarBenny Siegert <bsiegert@gmail.com>
      (cherry picked from commit 74f00094)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/408822
      
      
      Reviewed-by: default avatarAustin Clements <austin@google.com>
      c25b12fb
  6. Jul 12, 2022
  7. Jul 06, 2022
  8. Jun 29, 2022
  9. Jun 01, 2022
  10. May 31, 2022
  11. May 30, 2022
  12. May 27, 2022
    • David Taylor's avatar
      [release-branch.go1.17] crypto/tls: avoid extra allocations in steady-state Handshake calls · 03c2e56f
      David Taylor authored
      The Read and Write methods of *tls.Conn call Handshake
      unconditionally, every time they are called, expecting it to only
      perform a new handshake if required.
      
      However in go 1.17 handshakeContext was extended to set up a
      cancelable Context, and importantly did so prior to checking if a
      handshake is required. This thus causes it to allocate on every call,
      even in those that are no-ops when called in a Read or Write on an
      established connection, sometimes leading to very large numbers of
      allocations during reads.
      
      This change adds an early return, prior to setting up the context or
      proceeding into the handshakeMutex and checking the handshake error, if
      the handshake status atomic indicates handshake is already complete.
      
      name                                     old allocs/op  new allocs/op  delta
      Throughput/MaxPacket/1MB/TLSv12-10          1.07k ± 0%     0.62k ± 0%  -42.16%  (p=0.000 n=4+5)
      Throughput/MaxPacket/1MB/TLSv13-10          1.70k ± 0%     1.25k ± 0%     ~     (p=0.079 n=4+5)
      Throughput/MaxPacket/2MB/TLSv12-10          1.62k ± 0%     0.73k ± 0%  -55.18%  (p=0.008 n=5+5)
      Throughput/MaxPacket/2MB/TLSv13-10          2.26k ± 0%     1.36k ± 0%  -39.64%  (p=0.008 n=5+5)
      Throughput/MaxPacket/4MB/TLSv12-10          2.74k ± 0%     0.95k ± 0%  -65.35%  (p=0.008 n=5+5)
      Throughput/MaxPacket/4MB/TLSv13-10          3.37k ± 0%     1.58k ± 0%  -53.15%  (p=0.008 n=5+5)
      Throughput/MaxPacket/8MB/TLSv12-10          4.96k ± 0%     1.39k ± 0%  -72.06%  (p=0.016 n=4+5)
      Throughput/MaxPacket/8MB/TLSv13-10          5.60k ± 0%     2.01k ± 0%  -64.05%  (p=0.008 n=5+5)
      Throughput/MaxPacket/16MB/TLSv12-10         9.42k ± 0%     2.27k ± 1%  -75.92%  (p=0.016 n=4+5)
      Throughput/MaxPacket/16MB/TLSv13-10         10.0k ± 0%      2.9k ± 0%  -71.39%  (p=0.008 n=5+5)
      Throughput/MaxPacket/32MB/TLSv12-10         18.3k ± 0%      4.0k ± 0%  -77.97%  (p=0.008 n=5+5)
      Throughput/MaxPacket/32MB/TLSv13-10         18.9k ± 0%      4.6k ± 0%  -75.62%  (p=0.008 n=5+5)
      Throughput/MaxPacket/64MB/TLSv12-10         36.2k ± 0%      7.5k ± 0%  -79.15%  (p=0.008 n=5+5)
      Throughput/MaxPacket/64MB/TLSv13-10         36.7k ± 0%      8.1k ± 0%  -78.06%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/1MB/TLSv12-10      1.12k ± 0%     0.63k ± 0%  -44.20%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/1MB/TLSv13-10      1.76k ± 0%     1.26k ± 0%  -28.22%  (p=0.016 n=5+4)
      Throughput/DynamicPacket/2MB/TLSv12-10      1.68k ± 0%     0.74k ± 0%  -56.11%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/2MB/TLSv13-10      2.32k ± 0%     1.37k ± 0%  -40.80%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/4MB/TLSv12-10      2.80k ± 0%     0.96k ± 0%  -65.81%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/4MB/TLSv13-10      3.43k ± 0%     1.59k ± 0%  -53.57%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/8MB/TLSv12-10      5.03k ± 0%     1.39k ± 0%  -72.27%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/8MB/TLSv13-10      5.66k ± 0%     2.02k ± 0%  -64.27%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/16MB/TLSv12-10     9.48k ± 0%     2.28k ± 1%  -75.98%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/16MB/TLSv13-10     10.1k ± 0%      2.9k ± 0%  -71.34%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/32MB/TLSv12-10     18.4k ± 0%      4.0k ± 0%  -78.13%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/32MB/TLSv13-10     19.0k ± 0%      4.6k ± 0%  -75.54%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/64MB/TLSv12-10     36.2k ± 0%      7.6k ± 1%  -79.02%  (p=0.008 n=5+5)
      Throughput/DynamicPacket/64MB/TLSv13-10     36.8k ± 0%      8.2k ± 1%  -77.76%  (p=0.008 n=5+5)
      
      Fixes #52790
      
      Change-Id: Iacb1f9bf7802022960d9dbce141b8c0587a614d4
      Reviewed-on: https://go-review.googlesource.com/c/go/+/379034
      
      
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      TryBot-Result: Gopher Robot <gobot@golang.org>
      Reviewed-by: default avatarFilippo Valsorda <valsorda@google.com>
      Auto-Submit: Filippo Valsorda <filippo@golang.org>
      Run-TryBot: Filippo Valsorda <filippo@golang.org>
      (cherry picked from commit a4af3560)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/405544
      
      
      Reviewed-by: default avatarRoland Shoemaker <roland@golang.org>
      Reviewed-by: default avatarAlex Rakoczy <alex@golang.org>
      03c2e56f
    • Tatiana Bradley's avatar
      [release-branch.go1.17] crypto/tls: randomly generate ticket_age_add · c15a8e2d
      Tatiana Bradley authored
      As required by RFC 8446, section 4.6.1, ticket_age_add now holds a
      random 32-bit value. Before this change, this value was always set
      to 0.
      
      This change also documents the reasoning for always setting
      ticket_nonce to 0. The value ticket_nonce must be unique per
      connection, but we only ever send one ticket per connection.
      
      Updates #52814
      Fixes #52832
      Fixes CVE-2022-30629
      
      Change-Id: I6c2fc6ca0376b7b968abd59d6d3d3854c1ab68bb
      Reviewed-on: https://go-review.googlesource.com/c/go/+/405994
      
      
      Reviewed-by: default avatarTatiana Bradley <tatiana@golang.org>
      Reviewed-by: default avatarRoland Shoemaker <roland@golang.org>
      Run-TryBot: Tatiana Bradley <tatiana@golang.org>
      TryBot-Result: Gopher Robot <gobot@golang.org>
      (cherry picked from commit fe4de361)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/408574
      Run-TryBot: Roland Shoemaker <roland@golang.org>
      c15a8e2d
    • Russ Cox's avatar
      [release-branch.go1.17] os/exec: return clear error for missing cmd.Path · 590b53fa
      Russ Cox authored
      Following up on CL 403694, there is a bit of confusion about
      when Path is and isn't set, along with now the exported Err field.
      Catch the case where Path and Err (and lookPathErr) are all unset
      and give a helpful error.
      
      Updates #52574
      Followup after #43724.
      
      Fixes #53056
      Fixes CVE-2022-30580
      
      Change-Id: I03205172aef3801c3194f5098bdb93290c02b1b6
      Reviewed-on: https://go-review.googlesource.com/c/go/+/403759
      
      
      Reviewed-by: default avatarBryan Mills <bcmills@google.com>
      Reviewed-by: default avatarRoland Shoemaker <roland@golang.org>
      (cherry picked from commit 960ffa98)
      Reviewed-on: https://go-review.googlesource.com/c/go/+/408578
      Run-TryBot: Roland Shoemaker <roland@golang.org>
      TryBot-Result: Gopher Robot <gobot@golang.org>
      590b53fa
  13. May 25, 2022
  14. May 23, 2022
  15. May 18, 2022
  16. May 10, 2022
  17. May 09, 2022
Loading