1
0
mirror of https://github.com/golang/go synced 2024-11-26 16:57:14 -07:00
go/doc
Roland Shoemaker bc1da38c3d crypto/subtle: add DIT closure
Add a new function, WithDataIndependentTiming, which takes a function as
an argument, and encloses it with calls to set/unset the DIT PSTATE bit
on Arm64.

Since DIT is OS thread-local, for the duration of the execution of
WithDataIndependentTiming, we lock the goroutine to the OS thread, using
LockOSThread. For long running operations, this is likely to not be
performant, but we expect this to be tightly scoped around cryptographic
operations that have bounded execution times.

If locking to the OS thread turns out to be too slow, another option is
to add a bit to the g state indicating if a goroutine has DIT enabled,
and then have the scheduler enable/disable DIT when scheduling a g.

Additionally, we add a new GODEBUG, dataindependenttiming, which allows
setting DIT for an entire program. Running a program with
dataindependenttiming=1 enables DIT for the program during
initialization. In an ideal world PSTATE.DIT would be inherited from
the parent thread, so we'd only need to set it in the main thread and
then all subsequent threads would inherit the value. While this does
happen in the Linux kernel [0], it is not the case for darwin [1].
Rather than add complex logic to only set it on darwin for each new
thread, we just unconditionally set it in mstart1 and cgocallbackg1
regardless of the OS. DIT will already impose some overhead, and the
cost of setting the bit is only ~two instructions (CALL, MSR), so it
should be cheap enough.

Fixes #66450
Updates #49702

[0] e8bdb3c8be/arch/arm64/kernel/process.c (L373)
[1] 8d741a5de7/osfmk/arm64/status.c (L1666)

Change-Id: I78eda691ff9254b0415f2b54770e5850a0179749
Reviewed-on: https://go-review.googlesource.com/c/go/+/598336
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-19 16:47:03 +00:00
..
initial doc/initial, doc/next: add draft notice to introduction 2024-05-22 18:25:26 +00:00
next crypto/subtle: add DIT closure 2024-11-19 16:47:03 +00:00
asm.html doc: document PCALIGN directive 2023-11-28 19:15:27 +00:00
go1.17_spec.html doc: reference language version in pre-generic spec for easier recognition 2024-10-10 18:25:45 +00:00
go_mem.html doc/go_mem: fix broken paper link in go_mem.html 2024-11-12 17:16:27 +00:00
go_spec.html spec: document that alias declarations can have type parameters with 1.24 2024-10-02 00:58:01 +00:00
godebug.md crypto/subtle: add DIT closure 2024-11-19 16:47:03 +00:00
README.md doc: initialize next directory for Go 1.24 2024-07-22 17:55:04 +00:00

Release Notes

The initial and next subdirectories of this directory are for release notes.

For developers

Release notes should be added to next by editing existing files or creating new files. Do not add RELNOTE=yes comments in CLs. Instead, add a file to the CL (or ask the author to do so).

At the end of the development cycle, the files will be merged by being concatenated in sorted order by pathname. Files in the directory matching the glob "*stdlib/*minor" are treated specially. They should be in subdirectories corresponding to standard library package paths, and headings for those package paths will be generated automatically.

Files in this repo's api/next directory must have corresponding files in doc/next/*stdlib/*minor. The files should be in the subdirectory for the package with the new API, and should be named after the issue number of the API proposal. For example, if the directory 6-stdlib/99-minor is present, then an api/next file with the line

pkg net/http, function F #12345

should have a corresponding file named doc/next/6-stdlib/99-minor/net/http/12345.md. At a minimum, that file should contain either a full sentence or a TODO, ideally referring to a person with the responsibility to complete the note.

If your CL addresses an accepted proposal, mention the proposal issue number in your release note in the form /issue/NUMBER. A link to the issue in the text will have this form (see below). If you don't want to mention the issue in the text, add it as a comment:

<!-- go.dev/issue/12345 -->

If an accepted proposal is mentioned in a CL but not in the release notes, it will be flagged as a TODO by the automated tooling. That is true even for proposals that add API.

Use the following forms in your markdown:

[http.Request]                     # symbol documentation; auto-linked as in Go doc strings
[Request]                          # short form, for symbols in the package being documented
[net/http]                         # package link
[#12345](/issue/12345)             # GitHub issues
[CL 6789](/cl/6789)                # Gerrit changelists

To preview next content in merged form using a local instance of the website, run:

go run golang.org/x/website/cmd/golangorg@latest -goroot=..

Then open http://localhost:6060/doc/next. Refresh the page to see your latest edits.

For the release team

The relnote tool, at golang.org/x/build/cmd/relnote, operates on the files in doc/next.

As a release cycle nears completion, run relnote todo to get a list of unfinished release note work.

To prepare the release notes for a release, run relnote generate. That will merge the .md files in next into a single file. Atomically (as close to it as possible) add that file to _content/doc directory of the website repository and remove the doc/next directory in this repository.

To begin the next release development cycle, populate the contents of next with those of initial. From the repo root:

> cd doc
> cp -R initial/ next

Then edit next/1-intro.md to refer to the next version.