- Where: zoom.us
- When: May 14, 4pm-5pm UTC (May 14, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
- Contact:
- Name: Ben Smith
- Email: [email protected]
None required if you've attended before. Email Ben Smith to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Discuss: development of a WebAssembly dashboard (similar to wpt.fyi or test262.report)
- Update on custom annotations proposal (Andreas)
- spec, interpreter, tests complete (see this PR for details)
- POLL: promote to stage 3?
- Adding Security and Privacy section to spec
- Passive element segment binary format
- Slides
- The current format is more general, but larger (~3 bytes for function reference, allows heterogeneous segments)
- A suggested format is smaller, but less expressive (~1 byte for function reference, only homogeneous segments)
- Closure
None
None
- Alex Crichton
- Arun Purushan
- Conrad Watt
- Dan Gebhardt
- Dan Gohman
- David Piepgrass
- Deepti Gandluri
- Derek Schuff
- Francis McCabe
- Guanzhong Chen
- Heejin Ahn
- Jacob Gravelle
- Keith Miller
- Lars Hansen
- Lilit Darbinyan
- Luke Imhoff
- Luke Wagner
- Mark Miller
- Michael Starzinger
- Mingqui Sun
- Mitch Moore
- Nick Fitzgerald
- Pat Hickey
- Paul Dworzanski
- Paul Schoenfelder
- Peter Jensen
- Richard Winterton
- Shravan Narayan
- Sven Sauleau
- TatWai Chong
- Wouter van Oortmerssen
Jacob Seconds
BS: Review licensing issues for WASI, CLA specifically does not cover software - we can cover whatever license we like. Do the normal thing with SW licences. They suggest Apache. Any questions?
Discuss: development of a WebAssembly dashboard (similar to wpt.fyi or test262.report)
BS: Contacted by some people from Bocoup when adding some tests to WPT tests repository. We already have JS and web API tests in WPT. That PR has been stale for a while - concern was that they were not keen to open up an upstream, they are not excited about maintaining that because we need a new tool (Reference interpreter is required to convert wat files to JS). They suggested having a separate dashboard for Wasm tests. One reason, might be useful for non-web VMs to have a different dashboard.
Two questions - Are we interested? Who will pay for it - who will do the work?
AR: Argument that it’s useful for non-web uses, but how is it useful if it’s on the web?
BS: It’s just an easy place to query status. Take a look at test262.report or wpt.fyi for examples.
AR: Seems useful, someone has to do a lot of work initially, someone else has to maintain it. What happens when the engines are not maintained?
BT: They were receptive to doing work (Bocoup). I suggested they work on one-way sync as well.
PH: Fastly is interested in helping out
DE: There was interested in following up on BT’s design, not sure if we should agree so quickly that it should be separate.
BS: Raised a concern that we want to have them on WPT anyway so this may not be an “either” situation but “and”
AR: Why in both places then - seems like extra work?
BS: Maybe for non-web embeddings?
SS: Could you please send the link to the PR/Issue? I can't find it in the notes/agenda
BS: web-platform-tests/wpt#16321
FM: if we have a non web dashboard, does this involve splitting up the tests themselves - i.e., do the tests rely of web binding?
BS: We already have a precedent for this, tests are run in the environment that they’re relevant to.
BS: Trying to get a flavor of the room here, looks like there’s general interest, but also trying to push forward with WPT as well.
Meeting: [Silence]
BS: Taking it as a yes
Update on custom annotations proposal (Andreas)
- spec, interpreter, tests complete (see this PR for details)
- POLL: promote to stage 3?
AR: Specced, and implemented it - let me present.
Generic way of adding annotations to the text format - engines not affected. Have a way of adding s-expressions that start with @ - this could be a way to add custom ways of adding custom syntax. Some examples: binary contents of custom sections, name section, web-idl bindings. … Specifying a list of tokens in the spec Added name annotations, and custom annotations in the appendix (more informal spec of both of those) Saw some PRs for wabt?
BS: JG implemented some parts of it
AR: These are treated like a comment/whitespace, can be thrown away by a parser that doesn’t want to parse. Giving update that the Spec, and reference interpreter are complete - meets requirements for phase 3. This was possibly required for WebIDL proposal, so can we move forward to Phase 3?
JG: Have been playing around with this for the WebIDL bindings, useful to have.
TL: Useful for toolchain custom sections, is the producer section, or target feature section. @custom notation an example, or is it a recommended notation?
AR: Can go to the appendix to show it - dumps the contents of the custom sections, you only want to use it for sections you don’t understand.
JG: Is @custom part of the spec or a handshake that’s agreed upon?
AR: It’s like custom sections, you’re free to ignore it. Up to the tools to interpret
TL: Provide both the @custom, and the human readable form -- may have to specify it twice depending on the tools, whether they understand it or not.
AR: Handwaved around the problem, for e.g. you have name collisions it’s basically up to the tools to decide what to do with that - if you’re not able to interpret the names section then you don’t know much. But if you can interpret the name section then you can... don’t know how to define rules for this situation.
JG: Agree that it’s up to the tools - if you’re running your wat through a tool that doesn’t understand the custom section - what does it do?
TL: Preserve it for future tools hopefully.
JG: What about debug information? For metadata, preservation is important, but for others.
AR: There’s a lot we can do here - it’s a problem of the custom sections solution.
BT: There may not be a general solution, but a solution built on top of byte offsets is possible -- so something to think about it. If there was a convention for byte offsets, you could update it.
AR: We’re talking about custom sections now, not annotations. Relocating byte offsets in custom offsets is tricky, doesn’t seem like a general solution.
JG: Solving the general byte offset proposal seems out of scope for this proposal, including more info to indicate whether this is metadata may be useful - more of a tool convention problem.
AR: That’s a problem for custom sections first, right?
JG: It would be a tool convention.
BT: What are the mechanics of implementing a transformation function; do I implement it as an extension to a tool that processes a binary, is that what you had in mind?
JG: Your tool needs to understand the annotation -- it’s hard to specify byte offsets in general.
BT: Is the annotation processor implemented in the assembler, how does this work? I don’t want to create a processor for the entire text file just for my one section.
AR: You mean how to implement a generic parser? Gives you generic information about the custom annotations?
JG: If you’re not shipping your own assembler, then you need a plugin to do it.
AR: We have a version of the reference interpreter where we use custom sections -- the lexer spills out a big table of all custom sections with their source regions, and the AST is annotated with the source regions as well, so you can match them up. You could have a plugin sysmem for this - ultimately this is all out of scope for this spec.
JG: The wabt lexer also does this, where it keeps source information for each token. The parser then skips them if it doesn’t understand them.
TL: Lot’s of tool conventions that come out of this proposal -- if this proposal comes with a non-normative spec with custom annotations for names -- it would be good for them to be unambiguous about them -- how do they behave in custom sections.
AR: It’s in the appendix for a reason - if you find a name section that you don’t understand you can ignore it. For the name annotations I did the same level of preciseness.
FM: Did you consider following what the JVM does? They put a specific semantics in the binary for annotations. This is useful for class-loaders and dependency injection.
AR: You mean annotations in the bytecode stream?
FM:Yes, engine is free to ignore it -- is this an actual annotation or a glorified comment? If an actual annotation, then support modifying the bytestream as well.
JG: I would consider this to be a annotatable lexer comment.
BT: Agree with FM. There should be a default translation to a binary section, that would be the most useful.
JG: Useful, but very complex -- clarification as glorified comments is true, the niceness about this proposal is in its simplicity.
FM: If you modify the name of the function, it’s more than a comment.
AR: But the name has no semantic meaning. This is the same as custom sections -- it’s just a hook that tools can use.
BT: Because this is only in the text format, it’s only useful for the text format. [AR,JG: yes] Annotations don’t roundtrip.
AR: The idea is that you can roundtrip from binary to text and back, because you can use the @custom syntax. The other way only works if you forward annotations you understand.
BT: What Francis is saying is that the JVM doesn’t understand the annotations, but there’s a format to understand. Annotations are inherently tied to syntactic elements and this leaves it totally up to the tools how to use them.
AR: We would need to extend the binary format -- this would be a major change to the binary format.
BT: You don’t have to do that... we should have this discussion with more context about the JVM, and how it handles custom annotations.
FM: You can’t put an annotation anywhere in the JVM, it has to be in specific places the binary format reflects that.
AR: You realize you’re talking about the binary format and not the text format.
BS: We are now moving into the design space -- there seem to be a lot of open questions, design should move to the repository.
JG: I’ll continue to use this... What would be the purpose of standardizing?
BS: Needs to be in the spec.
AR: Having a more structured custom sections format -- we can overlay all of this on the current spec with more structure in tool conventions or someplace else. That was the intention all along, to keep the core spec minimal as possible, so you can overlay with more structure elsewhere. The main spec shouldn’t have all this detail -- does that make sense?
JG: Want to go there, but not in this proposal.
BS: We should have more discussion offline -- there’s enough difference of opinion.
AR: Concrete suggestions on how to move this forward?
BS: Have discussions about binary annotations, and whether it will be in the same proposal or outside.
AR: Should be a separate proposal, not sure if I understand the discussion anywhere.
FM: There is a difference between having a text representation of a custom section and annotations everywhere. In the case of the latter, is it expected that the tool preserve such annotations? (There are examples of ‘special comments’ in JS that JS tools need to preserve if they want to preserve the semantics of the JS module).
AR: It’s not.
JG: If you do not recognize the section, then don’t preserve this.
BT: Let’s talk about it offline. It’s likely that many tools will want to preserve the annotations by default.
DP (text comment): It seems to me that the @custom annotation specifically should be standardized now to enable round-tripping. Arbitrary annotations can simply be ignored by most tools for now, but the interpretation of them could be standardized later in a separate proposal. I would be curious to hear if people see a risk to allowing arbitrary annotations (e.g. conflicts between tools). Other than such risks, if any, the proposal (in general) seems reasonable to me.
BS: This is a bit of an annoying sticky point -- many W3 specs have this specific section, advised by the process document. In the core spec, privacy is hard to have an opinion on -- to what extent do we include the section that’s advised, but not super relevant.
EP: In the case of the W3 core spec, it’s useful to say that it’s a VM, and possibly not relevant to the core spec -- don’t think of it as a part of the spec, but tells people that it’s an annotation on the spec, and sets expectations. I’d like to tack it on to the end where people expect it -- so people that are not reading the spec, can look for it and find it. I also wanted to have a forward reference from the core spec’s privacy and security section out to the JS API spec, since it’s likely someone reading the core spec would wonder about it.
MM: I have questions -- not familiar with W3C practice with regard to specifying privacy/security -- Wasm itself has pretty strong security property, where is a good place to specify that?
EP: Can write a more detailed section, and point to the right place.
MM: Some examples of security properties -- wasm instance is not affected by outside influences, or sense effects other than granted by environment, forms a perfect sandbox for executing untrusted code. The export/import mechanism from one wasm instance to another, in the absence of shared memories or tables -- that’s a perfect domain crossing. The caller/callee can only interact through the semantics of the function. Wasm has no dynamic non-determinism, running single-threaded, in the absence of SABs -- no ability to sense duration -- it can signal, but not sense -- means that it’s protected from side-channels. Where do all these points belong?
EP: Current spec already covers a lot of these points.
AR: It also says explicitly that you can only interact with imports/exports. Talks about side channels vaguely -- don’t want to make specific statements given all that’s happened.
LW: Can count packets over the network, so others can sense duration.
MM: Right, any access to the outside world can enable indirect sensing of duration.
BT: NaN bits are non-deterministic.
MM: That aspect of the spec should be pinned down -- dynamic vs. non-dynamic non-determinism. We should spec that this needs to be stable on any one platform.
AR: That’s not easy -- CPUs do very random things we don’t want to tie it to that.
MM: Are there platforms where it can vary at runtime?
DG: There’s cases where you can migrate wasm across CPU platforms, so it would be a problem there.
EP: More detailed than required for this purpose, it’s really up to the embedder -- just the fact that it offers no attack surface that is not already offered by JS.
MM: It’s not the thing that it makes it weaker, but wasm semantics offer a stronger security guarantee.
EP: Right, we may be able to say a properly scoped embedding will eliminate side-channels.
BT: We should not have anything more about side channels already -- another source of non-determinism if resource exhaustion when trying to grow memory etc.
BS: Added to the discussion because we were discussing privacy -- don’t know the technical distinction between the two -- we can extend the security issues with more discussion. But what about privacy?
AR: Can’t say anything meaningful because it’s an ISA -- it’s not useful for the CPU to say anything about that.
EP: We should just say that.
AR: Do we want to say arbitrary things for people that don’t understand what they’re reading?
EP: Just clarifying that is useful.
AR: We should add in the Web API spec, it makes sense there, but it’s not relevant for the core spec.
EP: People will be looking for it.
EP+AR to follow up offline.
BS: Want to give an opportunity for someone who hasn’t already spoken up. [no one speaks up]
No time for this.