RFC First cut support for sandboxing procmacros with wasm #7297
Conversation
|
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
jsgf
changed the title
There was a problem hiding this comment.
Nice!
In the medium term, I would like for crates.io to distribute proc macros as precompiled wasm binaries -- which immediately eliminates all complaints about proc macros taking long to compile.
Is the implementation here forward compatible with a world where serde_derive = { version = "1.0", features = ["some", "features"] } serves me a precompiled wasm with the requested feature set? or do we need to ask that the macro author make some additional guarantees about the possible behavior of the macro when they opt in to wasm-sandbox = true.
|
If you assume features are additive then you could just set them all for prebuilt. Or if some are rare and bloaty then prebuilt could exclude them and you'd need to build locally if you want them. IOW the prebuilt would have associated features and resolution would work out whether it's usable. Of course it breaks if features are used wrongly. |
jsgf
force-pushed
the
wasm-procmacro
branch
2 times, most recently
from
d843872
to
f5e49fe
Compare
|
Thanks for getting started on this @jsgf! I think this has the rough shape of what will be necessary, but I think that we'll probably want to pursue the rustc changes first since they're likely the much more meaty ones for now. Some updates we'll need on the Cargo side eventually are:
I suspect we'll have some sort of different In terms of overall feature design I personally feel that precompiled wasm files distributed on crates.io is one of the biggest wins here and is one we'd want to flesh out before stabilizing everything. That doesn't necessarily needed to happen right here on this PR, but would likely be accompanied in the eventual RFC to flesh all this out. For example I do have concerns about what @dtolnay was mentioning with features but I also have concerns about transitive dependencies. For example the precompiled wasm file might use |
|
@alexcrichton I'm thinking that
Maybe, but is some logic being applied to Kind in this diff - for example, the build script for a Kind::HostSandbox target will be Host. I'm not how that would look if it were just strings. Now that this seems to have minimal correct functionality, I've moved into rustc. I'll put up a WIP RFC PR once I've made some headway. I expect it require further changes here. |
The rationale for this is that rustc doesn't support proc-macro as a crate type for wasm32, so use cdylib since its functioanlly equivalent to the crate type we'd want. But it doesn't work because a proc-macro crate also has language features that we still need to make available.
|
Based on discussion in the Cargo meeting, note that we don't want to consider this in any way a security feature, only an isolation feature to make it easier to treat macros as functions from inputs to outputs. |
|
@joshtriplett Totally on board with that characterization. |
|
☔ The latest upstream changes (presumably #7216) made this pull request unmergeable. Please resolve the merge conflicts. |
This commit is an internal refactoring of Cargo's compilation backend to eventually support compiling multiple target simultaneously. The original motivation for this came up in discussion of rust-lang#7297 and this has long been something I've intended to update Cargo for. Nothing in the backend currently exposes the ability to actually build multiple target simultaneously, but this should have no function change with respect to all current consumers. Eventually we'll need to refactor APIs of how you enter the compilation backend to compile for multiple targets.
Refactor `Kind` to carry target name in `Target` This commit is an internal refactoring of Cargo's compilation backend to eventually support compiling multiple target simultaneously. The original motivation for this came up in discussion of #7297 and this has long been something I've intended to update Cargo for. Nothing in the backend currently exposes the ability to actually build multiple target simultaneously, but this should have no function change with respect to all current consumers. Eventually we'll need to refactor APIs of how you enter the compilation backend to compile for multiple targets.
|
Ok this has been quiet for some time now and in the meantime we've had In any case we're certainly interested in continuing to investigate this as always, and we're more than willing to help discuss this in the future! |
|
@alexcrichton that links to rfc 2474, which doesn't seem right given the context. Did you mean to link to something else? |
|
Here is the link: https://github.com/dtolnay/watt |
|
Er yes sorry I apologize, @dtolnay has the right link. |
This is a first cut experiment at building proc-macros with wasm in order to sandbox them.
It adds a new
Kind:HostSandbox, in addition toHostandTarget. This is treated as a host build, but its alwayswasm32-unknown-unknown.In Cargo.toml, you can set
wasm_sandbox = truein addition toproc-macro = true, which enables the use ofHostSandbox.When the compilation actually happens, it's treated as a cross-build to wasm32-unknown-unknown.
Lightly tested on
serde, which worked until it couldn't findproc_macrofrom rustc (well, proc-macro2's build.rs assumes it can't exist and so fakes it out).Assuming this basic approach is sound, I'm thinking that the
wasm_sandboxflag will become a marker that the procmacro could be sandboxed, and then a command-line or cargo config option would request that procmacros be built sandboxed (with further config to forbid non-sandboxed).TODO:
cc @alexcrichton, @dtolnay