all: remove nacl port #30439

bradfitz · 2019-02-27T18:57:38Z

We propose to remove the nacl ports (for amd64p32, 386, and arm).

Nacl is deprecated in favor of WebAssembly and @rsc made the point that it's no longer even a great sandbox in light of all the speculative execution problems of late.

The only current user of nacl is the playground (https://play.golang.org/) which we'd need to move to something else. Perhaps gVisor's runsc (https://github.com/google/gvisor#gvisor).

Related: #30324 (for faking time, network)

/cc @randall77 @ianlancetaylor @rsc @aclements @davecheney @josharian @andybons @dmitshur

dmitshur · 2019-02-27T19:10:27Z

Related issue is #25224.

The only current user of nacl is the playground (https://play.golang.org/) which we'd need to move to something else. Perhaps gVisor's runsc (https://github.com/google/gvisor#gvisor).

To expand on that, another option to consider is WebAssembly.

WebAssembly use for playground details

If using WebAssembly, there exist choices for where the playground snippet code is compiled, and where it's executed. It can be compiled either on the backend server, or in the frontend client (user's browser). The compiled WebAssembly module (application/wasm) can be executed either on the backend sever, or in the frontend client. Some of these options are more difficult to implement than others and have trade-offs.

martisch · 2019-02-27T20:13:47Z

I think nacl is the only GOOS for GOARCH amd64p32. Can we therefore also remove all support for amd64p32 when removing nacl?

bradfitz · 2019-02-27T20:25:52Z

@martisch, yes. That's one of the main motivations.

ianlancetaylor · 2019-02-27T21:34:00Z

I'll note that gccgo uses GOARCH=amd64p32 for x32 mode (https://en.wikipedia.org/wiki/X32_ABI). In general I think we'll want to keep it if we ever choose to do an x32 mode port. Though I don't know how relevant x32 is for Go.

bradfitz · 2019-03-19T19:31:28Z

@kortschak brought up golang.org/x/tools/cmd/present too.

Currently the present tool has flags to either use play.golang.org or run locally. And when run locally, it has an option for whether to use nacl or not. It defaults to non-nacl, local execution (not using play.golang.org).

Adding gvisor support in present is probably onerous and wouldn't help e.g. people presenting on Mac or Windows laptops.

So, I think present should probably use WebAssembly. Then perhaps we could remove one of the two current flags and then the only choice would be remote play.golang.org vs local WebAssembly.

/cc @neelance @adg

neelance · 2019-03-19T19:50:18Z

There are two options for WebAssembly: Run the wasm binary on the client (in browser) or on the server (with Node.js or some other compatible wasm runtime).

When running it on the client the main issue is browser compatibility. I think for present it is not really a problem, because you usually can choose which browser to use for your presentation. For the playground however it might not be good to have it fail on incompatible browsers. On #28360 we said that (for now) wasm only needs to support the latest browsers. This requirement might not be suitable for the playground.

Running on the server however might be good for the playground, because we can take care of properly setting up the wasm runtime.

bradfitz · 2019-03-19T20:03:37Z

For the playground (play.golang.org), we'll run it on the server and not use WebAssembly, because we control the 1 server and we can use gvisor (or most likely: just use Google Cloud Functions, which uses gvisor)

For present, there are many user machines, so running WebAssembly is the best bet, and running it in the client is best so users don't need to worry about having nodejs installed. I don't imagine many people are going to be presenting on Blackberry's browser: https://caniuse.com/#feat=wasm

Re #28360 and browser compatibility, I believe my most recent comment is still what we want to do: #28360 (comment) ... that is, support the current stable releases of all evergreen browsers by default and only use experimental WebAssembly features behind a compiler-side flag like GOWASM=foo. Alternatively, if we really had to, we could go the other way and make present tell the compiler to do GOWASM=super-portable-at-the-cost-of-speed.

neelance · 2019-03-19T20:30:27Z

Re browser compatibility: Are we saying different things? I feel like we're saying the same but it sounds like you're disagreeing. Feel free to answer on #28360 so we don't clutter this thread.

kortschak · 2019-03-19T21:02:09Z

When running it on the client the main issue is browser compatibility. I think for present it is not really a problem, because you usually can choose which browser to use for your presentation.

This is part of the story. I use present for lectures with runnable code examples including code from outside the standard library. The present server is accessible to the students during the lectures and after. I have close to zero control over the machines they use.

adg · 2019-03-19T22:04:49Z

It would make sense to me to run code snippets using WebAssembly on the backend for both play.golang.org and present. One supported code path, the only external dependency would be some kind of JS runtime. gVisor/runsc means Docker, right? I investigated running short-lived processes on Cloud inside gVisor and it wasn't fast or easy to provision (weird permissions hacks starting Docker containers from inside Docker containers), but maybe I missed something.

bradfitz · 2019-03-19T22:09:16Z

@adg, App Engine and Google Cloud Functions use gvisor. So all we have to do is deploy a Google Cloud Function that runs the compiler & resulting binary. That part's trivial.

For the present case, though, we don't want a requirement for present users to be that they have nodejs installed. Hence server-side compilation to WebAssembly & client-side execution of WebAssembly.

adg · 2019-03-19T22:15:38Z

So all we have to do is deploy a Google Cloud Function that runs the compiler & resulting binary. That part's trivial.

Ah so you can deploy Cloud Functions that run code with restricted permissions (no network access)?

we don't want a requirement for present users to be that they have nodejs installed

That's fair. Although I'm curious to see how it goes, shipping megabytes of webasm to the browser on each 'run'.

bradfitz · 2019-03-19T22:25:19Z

Ah so you can deploy Cloud Functions that run code with restricted permissions (no network access)?

Yeah, I think that between porting nacl's faketime support to linux/amd64 (which @aclements has in progress) and restricting outbound network access via modifications to the net package, we could pretty much just use the resulting linux/amd64 binaries unmodified under gvisor: the real network stack (restricted to localhost) and the real filesystem (I'll have to check whether there are magic auth token files that would cause a problem). Worst case we also port over the nacl fake filesystem behind a build tag.

bradfitz · 2019-03-19T22:26:49Z

That's fair. Although I'm curious to see how it goes, shipping megabytes of webasm to the browser on each 'run'.

It's 14% smaller as of https://go-review.googlesource.com/c/go/+/167801 and 1.5% smaller with https://go-review.googlesource.com/c/go/+/167937 ... but megabytes isn't terrible terrible.

neelance · 2019-03-19T22:30:52Z

Gzip compression gives a size of 650 KB for "hello world" with fmt.

aclements · 2019-03-19T22:41:02Z

Ah so you can deploy Cloud Functions that run code with restricted permissions (no network access)? Yeah, I think that between porting nacl's faketime support to linux/amd64 (which @aclements <https://github.com/aclements> has in progress) and restricting outbound network access via modifications to the net package, we could pretty much just use the resulting linux/amd64 binaries unmodified under gvisor: the real network stack (restricted to localhost) and the real filesystem (I'll have to check whether there are magic auth token files that would cause a problem). Worst case we also port over the nacl fake filesystem behind a build tag.

If it's just a linux/amd64 binary, I worry that it could break out to the real network too easily. I wouldn't want to rely on language-level protection like modifying net and disabling "unsafe" alone to ensure something like this.

…

aclements · 2019-03-19T22:45:56Z

That's fair. Although I'm curious to see how it goes, shipping megabytes of webasm to the browser on each 'run'. It's 14% smaller as of https://go-review.googlesource.com/c/go/+/167801 and 1.5% smaller with https://go-review.googlesource.com/c/go/+/167937 ... but megabytes isn't *terrible* terrible.

A while back we floated the idea of doing modular wasm builds, so the runtime and std could be shipped as a cacheable wasm module. I assume nothing has happened on that because I probably would have heard. :)

…

bradfitz · 2019-03-19T22:46:27Z

Porting nacl's fake network was the original plan so I'm still fine with that too.

I forgot to mention child processes. If we use the Google App Engine/GCF/etc existing gvisor sandbox we'll also need to block child processes. Otherwise you could just write out a binary to do network access and run that. Or we could just use runsc in a VM with nested virt and define our own gvisor sandbox, and then not worry about faking network or disk. I'll try that first.

ianlancetaylor · 2019-03-20T17:39:10Z

To be conservative, I think we should announce removal of NaCl in the 1.13 release, and actually remove it in the 1.14 release.

bradfitz · 2019-03-20T17:39:39Z

I tweeted about this here: https://twitter.com/bradfitz/status/1108072470320304128

One potential user from the tweet replies: tinygo-org/tinygo#211 (comment)

andybons · 2019-03-27T17:49:12Z

Per discussion with @golang/proposal-review, 1.13 will be the last release to support it, with it being removed in 1.14.

Updates golang/go#30439 Change-Id: I46c7de8d16c3470f2f20a4d0e03b74bb38c8aff0 Reviewed-on: https://go-review.googlesource.com/c/tools/+/199500 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>

This is part two if the nacl removal. Part 1 was CL 199499. This CL removes amd64p32 support, which might be useful in the future if we implement the x32 ABI. It also removes the nacl bits in the toolchain, and some remaining nacl bits. Updates #30439 Change-Id: I2475d5bb066d1b474e00e40d95b520e7c2e286e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200077 Reviewed-by: Ian Lance Taylor <iant@golang.org>

gopherbot · 2019-10-10T16:33:16Z

Change https://golang.org/cl/200318 mentions this issue: all: remove nacl (part 3, more amd64p32)

Part 1: CL 199499 (GOOS nacl) Part 2: CL 200077 (amd64p32 files, toolchain) Part 3: stuff that arguably should've been part of Part 2, but I forgot one of my grep patterns when splitting the original CL up into two parts. This one might also have interesting stuff to resurrect for any future x32 ABI support. Updates #30439 Change-Id: I2b4143374a253a003666f3c69e776b7e456bdb9c Reviewed-on: https://go-review.googlesource.com/c/go/+/200318 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

gopherbot · 2019-10-11T16:53:23Z

Change https://golang.org/cl/200739 mentions this issue: runtime: move sighandler into signal_unix.go

We couldn't do this before because sighandler was compiled for nacl. Updates #30439 Change-Id: Ieec9938b6a1796c48d251cd8b1db1a42c25f3943 Reviewed-on: https://go-review.googlesource.com/c/go/+/200739 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

gopherbot · 2019-10-11T18:48:38Z

Change https://golang.org/cl/200765 mentions this issue: dashboard: disable nacl builders for the dev.link branch

Updates golang/go#30439 Change-Id: Ic2548709c4a55c2c8b29a4f074bcb3df8292a7c3 Reviewed-on: https://go-review.googlesource.com/c/build/+/200765 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

gopherbot · 2019-10-15T03:15:43Z

Change https://golang.org/cl/200941 mentions this issue: all: remove some nacl and amd64p32 stuff

Updates #30439 Change-Id: I7ef5301fbd650d26a37a1241ddf7ca1ccd58b89d Reviewed-on: https://go-review.googlesource.com/c/go/+/200941 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

gopherbot · 2019-10-16T06:10:22Z

Change https://golang.org/cl/201377 mentions this issue: cmd/internal/obj/arm: remove NaCl related DATABUNDLE

gopherbot · 2019-10-16T11:19:07Z

Change https://golang.org/cl/201380 mentions this issue: cmd/compile: remove amd64p32 related SSA rules

Updates #30439 Change-Id: Ieaf18b7cfd22a768eb1b7ac549ebc03637258876 Reviewed-on: https://go-review.googlesource.com/c/go/+/201377 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

gopherbot · 2019-10-19T16:44:56Z

Change https://golang.org/cl/202159 mentions this issue: cmd/compile: remove overflow pointer padding for nacl

CL 200077 removed nacl bits in the toolchain, but it misses the code to add pointer overflow padding, which is specific for nacl. This CL removes that part. Passes toolstash-check. Updates #30439 Change-Id: I1e77cade9f31690e16cd13d3445a98b500671252 Reviewed-on: https://go-review.googlesource.com/c/go/+/202159 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

Updates #30439 Change-Id: Iadc737e4c6bb05bb576fe4bb344ad92403697352 Reviewed-on: https://go-review.googlesource.com/c/go/+/201380 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>

gopherbot · 2019-10-31T23:15:53Z

Change https://golang.org/cl/204600 mentions this issue: cmd/compile: remove amd64p32 rules

And simplify the remaining rules. Updates #30439 Change-Id: Ib89dce16b17ae881824178346ed6ab895b79627e Reviewed-on: https://go-review.googlesource.com/c/go/+/204600 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

CL 190998 broke the nacl-386 builder, but nacl support is being dropped as of Go 1.14 anyway. Updates golang/go#30439 Change-Id: If9a7ea1230d4af0a127aeb14005063be4092cf84 Reviewed-on: https://go-review.googlesource.com/c/build/+/192537 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates golang/go#30439 Change-Id: Ic2548709c4a55c2c8b29a4f074bcb3df8292a7c3 Reviewed-on: https://go-review.googlesource.com/c/build/+/200765 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

This creates a VM (running Container-Optimized OS) with configuration such that it boots up and downloads/configures the runsc Docker runtime, reloading the existing Docker daemon on the VM, and then creates a new privileged Docker container with the host's /var/run/docker.sock available to the container. From within that container it's then possible for the new sandbox HTTP server to create its own Docker containers running under gvisor (using docker run --runtime=runsc). This then adds a regional us-central1 load balancer and instance group manager & instane template to run these VMs automatically across us-central1. Then the play.golang.org frontend can hit that URL (http://sandbox.play-sandbox-fwd.il4.us-central1.lb.golang-org.internal) Fixes golang/go#25224 Updates golang/go#30439 (remove nacl) Updates golang/go#33629 (this CL makes the playground support 2 versions) Change-Id: I56c8a86875abcde9d29fa7592b23c0ecd3861458 Reviewed-on: https://go-review.googlesource.com/c/playground/+/195983 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

bradfitz · 2020-05-03T04:59:39Z

Go 1.14 is out so I'm calling this done: https://golang.org/doc/go1.14#nacl

@toothrot will likely keep improving the gVisor-based playground but other bugs can/do track that.

gopherbot · 2020-10-07T15:27:57Z

Change https://golang.org/cl/260200 mentions this issue: dashboard, env/linux-x86-nacl: remove nacl builders and supporting files

Go 1.13 was the last release with nacl, and it's not supported by now. For golang/go#30439. Change-Id: Ic690aa388ab4505d5e755bbe40fed850a7300c69 Reviewed-on: https://go-review.googlesource.com/c/build/+/260200 Trust: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>

gopherbot added this to the Proposal milestone Feb 27, 2019

gopherbot added the Proposal label Feb 27, 2019

bcmills added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Feb 28, 2019

bradfitz mentioned this issue Mar 11, 2019

x/sys/cpu: tests fail on nacl #30733

Closed

bradfitz mentioned this issue Mar 20, 2019

all: support Go 1.12 tinygo-org/tinygo#211

Merged

andybons added Proposal-Accepted and removed Proposal labels Mar 27, 2019

gopherbot added the Proposal label Mar 27, 2019

andybons changed the title ~~proposal: remove nacl port~~ all: remove nacl port Mar 27, 2019

agnivade mentioned this issue Oct 10, 2019

hash/crc32: port faster CRC32-C implementation from AMD64 to AMD64P32 #16908

Closed

bradfitz closed this as completed May 3, 2020

aclements mentioned this issue Sep 15, 2020

x/playground: falsely detects a deadlock when running Cmd.StderrPipe example code #41202

Open

golang locked and limited conversation to collaborators Oct 7, 2021

gopherbot added the FrozenDueToAge label Oct 7, 2021

rsc unassigned bradfitz Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

all: remove nacl port #30439

all: remove nacl port #30439

bradfitz commented Feb 27, 2019

dmitshur commented Feb 27, 2019 •

edited

martisch commented Feb 27, 2019

bradfitz commented Feb 27, 2019

ianlancetaylor commented Feb 27, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

kortschak commented Mar 19, 2019

adg commented Mar 19, 2019

bradfitz commented Mar 19, 2019

adg commented Mar 19, 2019

bradfitz commented Mar 19, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

aclements commented Mar 19, 2019 via email

aclements commented Mar 19, 2019 via email

bradfitz commented Mar 19, 2019

ianlancetaylor commented Mar 20, 2019

bradfitz commented Mar 20, 2019

andybons commented Mar 27, 2019

gopherbot commented Oct 10, 2019

gopherbot commented Oct 11, 2019

gopherbot commented Oct 11, 2019

gopherbot commented Oct 15, 2019

gopherbot commented Oct 16, 2019

gopherbot commented Oct 16, 2019

gopherbot commented Oct 19, 2019

gopherbot commented Oct 31, 2019

bradfitz commented May 3, 2020

gopherbot commented Oct 7, 2020

all: remove nacl port #30439

all: remove nacl port #30439

Comments

bradfitz commented Feb 27, 2019

dmitshur commented Feb 27, 2019 • edited

martisch commented Feb 27, 2019

bradfitz commented Feb 27, 2019

ianlancetaylor commented Feb 27, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

kortschak commented Mar 19, 2019

adg commented Mar 19, 2019

bradfitz commented Mar 19, 2019

adg commented Mar 19, 2019

bradfitz commented Mar 19, 2019

bradfitz commented Mar 19, 2019

neelance commented Mar 19, 2019

aclements commented Mar 19, 2019 via email

aclements commented Mar 19, 2019 via email

bradfitz commented Mar 19, 2019

ianlancetaylor commented Mar 20, 2019

bradfitz commented Mar 20, 2019

andybons commented Mar 27, 2019

gopherbot commented Oct 10, 2019

gopherbot commented Oct 11, 2019

gopherbot commented Oct 11, 2019

gopherbot commented Oct 15, 2019

gopherbot commented Oct 16, 2019

gopherbot commented Oct 16, 2019

gopherbot commented Oct 19, 2019

gopherbot commented Oct 31, 2019

bradfitz commented May 3, 2020

gopherbot commented Oct 7, 2020

dmitshur commented Feb 27, 2019 •

edited