WASM and ocaps

68 views
Skip to first unread message

Mark Miller

unread,
Nov 3, 2017, 5:56:53 PM11/3/17
to cap-...@googlegroups.com, Discussion of E and other capability languages, fr...@googlegroups.com, Google Caja Discuss, Andreas Rossberg, Bradley Nelson
At the latest wasm (Web Assembly) standards meeting, I pointed out that wasm is already an OS-like ocap system: A wasm instance, with its linear data space + table of opaque external functions/objects is already a process-granularity-like unit of isolation with an address space and a clist. A wasm computation addresses its clist entries by clist index as expected. In addition, wasm currently obeys the following restriction.

> WebAssembly instances must never be able to cause effects other than by wielding explicitly granted access (e.g. the importObject in a JS embedding).

According to Andreas Rossberg (cc'ed), this is on purpose, even though the people in the room at the time did not seem to know that. I suggested that it be made normative, so security uses of this restriction would not be compromised by later "enhancements" that accidentally break this unarticulated restriction.

is the one to watch. Assuming I do a good job clarifying the agreement we just came to, and assuming the agreement holds in the face of these clarifications, it looks like wasm will explicitly be the object-capability system it was designed to be.

Andreas and Bradley (also cc'ed), please clarify or expand as appropriate. If you don't want to subscribe to these lists, send your posts to me and I will forward. Thanks.

--
  Cheers,
  --MarkM

Mark Miller

unread,
Nov 4, 2017, 7:13:17 AM11/4/17
to cap-...@googlegroups.com, fr...@googlegroups.com, Discussion of E and other capability languages, Google Caja Discuss, Bradley Nelson, Ben L. Titzer, Andreas Rossberg
[Forwarded by request]


On Sat, Nov 4, 2017 at 1:17 AM, Andreas Rossberg <ross...@mpi-sws.org> wrote:
To clarify for the broader crowd, to me this quote about (module) instances just describes an aspect of proper modularity, which naturally consists of two dual properties:

1. A module can only access what it (is given as) imports.
2. A client can only access what a module exports.

Of course, whether this implies an “ocap" system also depends on what exactly “what” quantifiers over. Formally this usually refers to free names or variables or addresses, which of course could still be side-stepped by a language providing ambient capabilities in an unnamed fashion, e.g. as primitive instructions.

Ben Titzer (CC’ed) initially prototyped Wasm that way, and as far as he told me, he consciously decided not to include any such primitives, even though he didn’t frame it as ocap. Given the diversity of environments that Wasm is supposed to be embeddable in that is almost a necessity: there practically is no interesting (non-computational) resource that can be assumed to exist in all possible embeddings, and hence you cannot build any into the language even if you wanted. In particular, Wasm shall neither depend on the web nor JavaScript nor any specific form of OS.

(A minor quibble I have with the quote is formulating the “what” as “effects”, because under the usual semantic interpretation of the term, a Wasm computation can still have observable effects, such as traps, non-determinism, or non-termination. But these (hopefully) are benign effects wrt security considerations.)

/Andreas


I suspect that most people in the room just



--
  Cheers,
  --MarkM

Mark Miller

unread,
Nov 4, 2017, 7:34:51 AM11/4/17
to cap-...@googlegroups.com, fr...@googlegroups.com, Discussion of E and other capability languages, Google Caja Discuss, Bradley Nelson, Ben L. Titzer, Andreas Rossberg
On these lists, sometimes we cross-post when introducing a topic but then announce that further discussion is to continue on one of these lists. For this topic I think the appropriate list is e-lang.
I will reply to Andreas there.
--
  Cheers,
  --MarkM
Reply all
Reply to author
Forward
0 new messages