25 ms·

Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can

by lambda 7y ago

Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it. I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be used to give a process direct access to shared memory safely. I don't know if that could be done with low enough overhead for small objects, it's possible that there would need to be a threshold below which you would just copy values to be efficient, but it seems like exploring fat pointer capabilities would be worthwhile. Memory mapping files or inter-process shared memory is the very coarse-grained version of this, using hardware protection. I feel like it should be possible to do something more efficient and finer grained with pointer capabilities and the static type checking that is done to verify WASM during compilation, but it may be a significant research project of its own.

tschneidereit 7y ago
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't require GC support as a base concept, so we have to treat a nanoprocess as the unit of isolation from the outside. Once we have GC support, nothing will prevent languages that can use it from expressing finer-grained capabilities even within a nanoprocess, and that seems highly desirable indeed. (full disclosure: I'm a Mozilla employee and one of the people who set up the Bytecode Alliance.)
- danielearwicker 7y ago
  That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).
  - tschneidereit 7y ago
    Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)
    - lambda 7y ago
      Yes, one of the answers I want to give any time someone asks "why will WASM succeed when the JVM didn't" is that there is 25 years more experience and research to draw upon.
      - pjmlp 7y ago
        And yet bounds checking access validation was left out of the design, something that most of previous research projects took care to taint as unsafe packages when present.
- lambda 7y ago
  What would allow other languages to represent unforgeable pointers as a first class concept and not C/C++/Rust? Forging a pointer is UB in all of these languages as far as I know. It seems like you should be able to have opaque types that represent these unforgeable pointers which you can't do arithmetic on or cast to raw pointers, but can access values in type safe ways, or provide a view to a byte slice which does bounds check on access. Is there a good place for discussion of this design? I seem to be having this conversation with you and Josh both here and on Reddit, and it seems like a lot of the discussion is spread out in a lot of places.
  - afiori 7y ago
    In unsafe rust you can arbitrarily increase the length of a vector/string by modifying the stored length. You do not need to forge the pointer itself to break the pointer's invariant.
    - lambda 7y ago
      You would need to do either static or dynamic bounds checking when accessing memory via these capabilities. You obviously can't just give arbitrary code a pointer and let it read however far it wants past the end of it. Given that most code in Rust is safe code and includes bounds checks before access, you should be able to have the verifier rely on those when they exist, and add in bounds checks in cases in which the access is not protected by a bounds check. Maybe that would be intractable, or to inefficient to be worth it with all of the extra bounds checks. I'm not sure. I'm asking because it's something that I feel should be possible, but I haven't been involved in the research or development, so I'm wondering if those who have been more involved have references to discussion about the topic.
- saagarjha 7y ago
  > For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. The semantics of these languages aren’t incompatible with unforgeable references, though: it generally works in practice, but it’s technically undefined to create pointers out of thin air. Why can’t we take advantage of the standard here to disallow illegally created references? (Which, as I understand it, many other vendors are already beginning to do with e.g. pointer authentication and memory tagging.)
  - steven_is_false 7y ago
    It's slow. You should read up on the challenges of implementing memcpy in C emulated on Java. Basically you have to manually implement paging.
- steven_is_false 7y ago
  >Since we want to support those languages as first-class citizens, we can't require GC support as a base concept I feel like you're overthinking it. Can't you just have a table that holds GCable objects and only hand out indexes to C and co?
  - tschneidereit 7y ago
    That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory. It doesn't help with making capabilities more fine-grained, though: we have to treat all code that has access to that table as having the same level of trust.

by lambda 7y ago

tschneidereit 7y ago

What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't require GC support as a base concept, so we have to treat a nanoprocess as the unit of isolation from the outside. Once we have GC support, nothing will prevent languages that can use it from expressing finer-grained capabilities even within a nanoprocess, and that seems highly desirable indeed. (full disclosure: I'm a Mozilla employee and one of the people who set up the Bytecode Alliance.)

danielearwicker 7y ago
That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).
- tschneidereit 7y ago
  Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)
  - lambda 7y ago
    Yes, one of the answers I want to give any time someone asks "why will WASM succeed when the JVM didn't" is that there is 25 years more experience and research to draw upon.
    - pjmlp 7y ago
      And yet bounds checking access validation was left out of the design, something that most of previous research projects took care to taint as unsafe packages when present.
lambda 7y ago
What would allow other languages to represent unforgeable pointers as a first class concept and not C/C++/Rust? Forging a pointer is UB in all of these languages as far as I know. It seems like you should be able to have opaque types that represent these unforgeable pointers which you can't do arithmetic on or cast to raw pointers, but can access values in type safe ways, or provide a view to a byte slice which does bounds check on access. Is there a good place for discussion of this design? I seem to be having this conversation with you and Josh both here and on Reddit, and it seems like a lot of the discussion is spread out in a lot of places.
- afiori 7y ago
  In unsafe rust you can arbitrarily increase the length of a vector/string by modifying the stored length. You do not need to forge the pointer itself to break the pointer's invariant.
  - lambda 7y ago
    You would need to do either static or dynamic bounds checking when accessing memory via these capabilities. You obviously can't just give arbitrary code a pointer and let it read however far it wants past the end of it. Given that most code in Rust is safe code and includes bounds checks before access, you should be able to have the verifier rely on those when they exist, and add in bounds checks in cases in which the access is not protected by a bounds check. Maybe that would be intractable, or to inefficient to be worth it with all of the extra bounds checks. I'm not sure. I'm asking because it's something that I feel should be possible, but I haven't been involved in the research or development, so I'm wondering if those who have been more involved have references to discussion about the topic.
saagarjha 7y ago
> For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. The semantics of these languages aren’t incompatible with unforgeable references, though: it generally works in practice, but it’s technically undefined to create pointers out of thin air. Why can’t we take advantage of the standard here to disallow illegally created references? (Which, as I understand it, many other vendors are already beginning to do with e.g. pointer authentication and memory tagging.)
- steven_is_false 7y ago
  It's slow. You should read up on the challenges of implementing memcpy in C emulated on Java. Basically you have to manually implement paging.
steven_is_false 7y ago
>Since we want to support those languages as first-class citizens, we can't require GC support as a base concept I feel like you're overthinking it. Can't you just have a table that holds GCable objects and only hand out indexes to C and co?
- tschneidereit 7y ago
  That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory. It doesn't help with making capabilities more fine-grained, though: we have to treat all code that has access to that table as having the same level of trust.