7 ms·

WASI: WebAssembly System Interface

123 points by teleforce 3y ago

tempodox 3y ago
There is the WASI SDK if you want to target WASI from C/C++: https://github.com/WebAssembly/wasi-sdk https://github.com/WebAssembly/wasi-sdk It comes with a libc implemented in WASM.
- jedisct1 3y ago
  A common option for that purpose is Zig. WASI is just one of the many targets it can compile C code to, out of the box: `zig cc -target wasm32-wasi`. No need to install yet another LLVM copy. Zig produces more optimized code, because it optimizes the libc like the rest of the application. So you can enable additional WebAssembly features according to the target runtime, for example `zig cc -target wasm32-wasi -mcpu=baseline+bulk_memory+simd128`. And you get automatic caching for free.
  - tempodox 3y ago
    That's cool and all, but how do I get it to use a linker that understands those options I give to `wasm-ld` (`--allow-undefined`, `--export-all`, `--no-entry`)? As it is, I'm getting “error: unsupported linker arg: --allow-undefined” when I pass that with `-Wl,`.
    - jedisct1 3y ago
      -Wl,--import-symbols -Wl,--export-all-symbols -Wl,--entry= (or rather -mexec-model=reactor).
eyberg 3y ago
[flagged]
- paulgb 3y ago
  The Wasm security model is to isolate at the module level. Each module gets its own isolated linear memory, and is prevented from reading another module's memory. A module is not prevented from reading its own memory via a pointer, nor should it be.
  - eyberg 3y ago
    So it is cool if you allow an attacker to change the program inside? Not cool. We were doing this back in the 90s.
    - josephg 3y ago
      I don’t think wasm supports polymorphic code. I’m pretty sure the code section of a wasm module is not modifiable. It might not even be readable by the module itself. The point of wasm is to allow C code to run unmodified, safely, and with as little performance degradation as possible. Sandboxing will mitigate a huge percentage of security vulnerabilities in wasm modules but C is still C. If you want better memory safety, use wasm with a memory safe language.
      - eyberg 3y ago
        The problem as I pointed out in another thread is that it doesn't matter if you are using something like rust. Wasm downgrades rust memory safety "guarantees" because those guarantees are only truly enforced by the operating system.
        junon 3y ago
        Sorry to be blunt but this is a completely nonsense comment that severely misunderstands how applications, memory, Rust and operating systems work together.
        slimsag 3y ago
        It's actually the hardware that enforces such guarantees. The OS could have bugs, like the WASM program - even if the entire stack is written in Rust from top to bottom. Really the only solution is memory safe hardware, which there is effort going into, e.g. ARM CHERI[0] and ARM MTE [0] https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/ https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/
deleted 3y ago
[deleted]
SnowProblem 3y ago
I've never seen a worse-described project than WASI. "Component model interfaces always support link-time interposition." Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.md https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec? I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html.
- skybrian 3y ago
  They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it. It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.
  - jedisct1 3y ago
    You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs. No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere. But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds"). Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.
syrusakbary 3y ago
I’m happy to see more excitement on the Wasm area. For the cases where you may need full POSIX compatibility for sockets, threads, signals or even fork or longjmp/setjmp, I’d recommend using WASIX [1] (also referenced in other comments here) since it has implemented all those system calls missing from WASI. [1]: https://wasix.org https://wasix.org
- FragenAntworten 3y ago
  Relevant but not mentioned: syrusakbary is the CEO of Wasmer, the company behind WASIX. I'm personally excited by WASIX (WASI has stagnated too long), but if you recommend something you have a part in, I think you should mention it.
  - syrusakbary 3y ago
    That’s me! Hopefully the extra info provided would be useful for some :)
  - jedisct1 3y ago
    Runtimes didn't wait for WASIX to start adding missing system calls to WASI. But WASIX brings a central place to document all this. And I don't think WASIX is fundamentally incompatible with the future WASI. The different ABIs doesn't make this straightforward, but WASIX could be available as WASI extension like others.
  - laerus 3y ago
    The guy that tried to trademark the Webassembly name btw and it's constantly trying to hijack the community with halfbaked solutions instead of pushing forward the standard, cause Wasmer had beef in the past with bytecode alliance peeps. WASI and WASM move slow for a good reason, This is how proper science and engineering works. The "go fast and break things" mentality of silicon valley startups has mainly filled the industry with low quality software.
    - jeffparsons 3y ago
      I imagine Wasmer must be in a bit of a difficult place right now. My understanding is that they are VC-backed (YC?), which means they're essentially trying to figure out how to make a huge amount of money off an open standard or something adjacent to it. But then, they would have known this from the very start, so I'm not sure what they expected, or why a VC firm would even look at them as a promising prospect. Maybe they hoped to be like Docker, where the value-add was cohesive higher-level tooling on top of all the lower-level bits. If that's the case, then WASI would be an existential threat in that it (and the tooling people are building around it) commoditizes what would otherwise be Wasmer's special sauce. I'm speculating wildly, of course, but it would at least be consistent with Wasmer's/Sirius's apparent vendetta against WASI and the people working on it. I hope Wasmer eventually finds a way to add value that doesn't rely on constant gaslighting and white-anting the standards process.
yankput 3y ago
WASI is kind of in a hard place now There is the version 1 which is not allowed to continue for political reasons (and that’s the one that everyone is implementing because it actually works) and there is version 2 that redoes everything from 0. Also there is wasix from an entirely different team that builds on top of version 1
- jeffparsons 3y ago
  > version 1 You mean preview 1? It was never meant to be a finished spec that would remain supported long-term; it was a preview for early adopters and people working in the space to experiment with. > allowed to continue for political reasons Uh... what?
  - yankput 3y ago
    There is no development on the preview 1; and the new development went in new direction so the preview1 or snapshot1 or whatever is the name is stuck Luckily the wasix is more pragmatic and continues where that left off
    - jeffparsons 3y ago
      Genuinely curious: what are you working on that makes POSIX compatibility important, but also warrants using Wasm instead of just building native executables? I ask because I'm personally much more excited about the future of WASI, because it brings so much to the table that it feels like it's actually worth the effort of building something new — I see it as a game changer. I.e. what you appear to view as an unnecessary diversion, I see as the whole point. So I'd love to understand more about your perspective and use case.
- jedisct1 3y ago
  And there are runtimes and services implementing their own APIs, and there's emscripten which is how most people actually use WebAssembly today. But if you're not porting existing software and only care about the web, these APIs are not very relevant. Oh, and WebAssembly also looks very different if you are using it for smart contracts. This is due to the fact that WebAssembly was not specified with an API to actually use it. But it's okay. CPUs don't ship with an operating system either. It doesn't make them useless, nor prevents multiple operating systems from existing.

123 points by teleforce 3y ago

There is the WASI SDK if you want to target WASI from C/C++: https://github.com/WebAssembly/wasi-sdk https://github.com/WebAssembly/wasi-sdk It comes with a libc implemented in WASM.

jedisct1 3y ago
A common option for that purpose is Zig. WASI is just one of the many targets it can compile C code to, out of the box: `zig cc -target wasm32-wasi`. No need to install yet another LLVM copy. Zig produces more optimized code, because it optimizes the libc like the rest of the application. So you can enable additional WebAssembly features according to the target runtime, for example `zig cc -target wasm32-wasi -mcpu=baseline+bulk_memory+simd128`. And you get automatic caching for free.
- tempodox 3y ago
  That's cool and all, but how do I get it to use a linker that understands those options I give to `wasm-ld` (`--allow-undefined`, `--export-all`, `--no-entry`)? As it is, I'm getting “error: unsupported linker arg: --allow-undefined” when I pass that with `-Wl,`.
  - jedisct1 3y ago
    -Wl,--import-symbols -Wl,--export-all-symbols -Wl,--entry= (or rather -mexec-model=reactor).

eyberg 3y ago

[flagged]

paulgb 3y ago
The Wasm security model is to isolate at the module level. Each module gets its own isolated linear memory, and is prevented from reading another module's memory. A module is not prevented from reading its own memory via a pointer, nor should it be.
- eyberg 3y ago
  So it is cool if you allow an attacker to change the program inside? Not cool. We were doing this back in the 90s.
  - josephg 3y ago
    I don’t think wasm supports polymorphic code. I’m pretty sure the code section of a wasm module is not modifiable. It might not even be readable by the module itself. The point of wasm is to allow C code to run unmodified, safely, and with as little performance degradation as possible. Sandboxing will mitigate a huge percentage of security vulnerabilities in wasm modules but C is still C. If you want better memory safety, use wasm with a memory safe language.
    - eyberg 3y ago
      The problem as I pointed out in another thread is that it doesn't matter if you are using something like rust. Wasm downgrades rust memory safety "guarantees" because those guarantees are only truly enforced by the operating system.
      - junon 3y ago
        Sorry to be blunt but this is a completely nonsense comment that severely misunderstands how applications, memory, Rust and operating systems work together.
      - slimsag 3y ago
        It's actually the hardware that enforces such guarantees. The OS could have bugs, like the WASM program - even if the entire stack is written in Rust from top to bottom. Really the only solution is memory safe hardware, which there is effort going into, e.g. ARM CHERI[0] and ARM MTE [0] https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/ https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

deleted 3y ago

[deleted]

SnowProblem 3y ago

I've never seen a worse-described project than WASI. "Component model interfaces always support link-time interposition." Like WTF does this mean? The repo tells me nothing and I've still yet to see a clear write-up about what WASI is. I click on "docs" folder and there's one file. https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.md https://github.com/WebAssembly/WASI/blob/main/docs/WitInWasi.... WTF is wit? This should be in a CONTRIBUTORS.md not in the docs folder. I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs. Wikipedia tells me WASI is a POSIX-like interface but with POSIX I know exactly where to look up the functions. Where's a single well-written WASI spec? I'll be honest - this whole project feels like candy for architecture astronauts and goes against the spirit of WebAssembly. Looks at how well-written WebAssembly's goals are: https://webassembly.org/docs/high-level-goals/ https://webassembly.org/docs/high-level-goals/. Their spec is easy to find and easy to read. This is what I want from WASM. Whatever WASI is doing, I don't like it. And neither does AssemblyScript team apparently: https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html.

skybrian 3y ago
They mean that an environment can always provide a fake version of a function to a webassembly program. They’re defining an API but there’s no requirement to implement it. It seems like a rather weak specification where nothing is required to work? But at least it defines an interface. You might compare it to Go or Java interface types.
- jedisct1 3y ago
  You're referring to yet another part of WASI, which is indeed about defining domain-specific sets of APIs. No specific set is required to be implemented. So an application can work somewhere, and not load elsewhere. But the idea is that similar environments will hopefully implement similar APIs, and there's a mechanism to encourage that ("worlds"). Not only interfaces are defined. As an illustration, the WASI Crypto proposal includes a lot of details on how individual functions must behave, because in this context, it's critical to avoid inconsistencies between implementations.

syrusakbary 3y ago

I’m happy to see more excitement on the Wasm area. For the cases where you may need full POSIX compatibility for sockets, threads, signals or even fork or longjmp/setjmp, I’d recommend using WASIX [1] (also referenced in other comments here) since it has implemented all those system calls missing from WASI. [1]: https://wasix.org https://wasix.org

FragenAntworten 3y ago
Relevant but not mentioned: syrusakbary is the CEO of Wasmer, the company behind WASIX. I'm personally excited by WASIX (WASI has stagnated too long), but if you recommend something you have a part in, I think you should mention it.
- syrusakbary 3y ago
  That’s me! Hopefully the extra info provided would be useful for some :)
- jedisct1 3y ago
  Runtimes didn't wait for WASIX to start adding missing system calls to WASI. But WASIX brings a central place to document all this. And I don't think WASIX is fundamentally incompatible with the future WASI. The different ABIs doesn't make this straightforward, but WASIX could be available as WASI extension like others.
- laerus 3y ago
  The guy that tried to trademark the Webassembly name btw and it's constantly trying to hijack the community with halfbaked solutions instead of pushing forward the standard, cause Wasmer had beef in the past with bytecode alliance peeps. WASI and WASM move slow for a good reason, This is how proper science and engineering works. The "go fast and break things" mentality of silicon valley startups has mainly filled the industry with low quality software.
  - jeffparsons 3y ago
    I imagine Wasmer must be in a bit of a difficult place right now. My understanding is that they are VC-backed (YC?), which means they're essentially trying to figure out how to make a huge amount of money off an open standard or something adjacent to it. But then, they would have known this from the very start, so I'm not sure what they expected, or why a VC firm would even look at them as a promising prospect. Maybe they hoped to be like Docker, where the value-add was cohesive higher-level tooling on top of all the lower-level bits. If that's the case, then WASI would be an existential threat in that it (and the tooling people are building around it) commoditizes what would otherwise be Wasmer's special sauce. I'm speculating wildly, of course, but it would at least be consistent with Wasmer's/Sirius's apparent vendetta against WASI and the people working on it. I hope Wasmer eventually finds a way to add value that doesn't rely on constant gaslighting and white-anting the standards process.

yankput 3y ago

WASI is kind of in a hard place now There is the version 1 which is not allowed to continue for political reasons (and that’s the one that everyone is implementing because it actually works) and there is version 2 that redoes everything from 0. Also there is wasix from an entirely different team that builds on top of version 1

jeffparsons 3y ago
> version 1 You mean preview 1? It was never meant to be a finished spec that would remain supported long-term; it was a preview for early adopters and people working in the space to experiment with. > allowed to continue for political reasons Uh... what?
- yankput 3y ago
  There is no development on the preview 1; and the new development went in new direction so the preview1 or snapshot1 or whatever is the name is stuck Luckily the wasix is more pragmatic and continues where that left off
  - jeffparsons 3y ago
    Genuinely curious: what are you working on that makes POSIX compatibility important, but also warrants using Wasm instead of just building native executables? I ask because I'm personally much more excited about the future of WASI, because it brings so much to the table that it feels like it's actually worth the effort of building something new — I see it as a game changer. I.e. what you appear to view as an unnecessary diversion, I see as the whole point. So I'd love to understand more about your perspective and use case.
jedisct1 3y ago
And there are runtimes and services implementing their own APIs, and there's emscripten which is how most people actually use WebAssembly today. But if you're not porting existing software and only care about the web, these APIs are not very relevant. Oh, and WebAssembly also looks very different if you are using it for smart contracts. This is due to the fact that WebAssembly was not specified with an API to actually use it. But it's okay. CPUs don't ship with an operating system either. It doesn't make them useless, nor prevents multiple operating systems from existing.