-
Notifications
You must be signed in to change notification settings - Fork 698
Provide overview of security model #717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Awesome, thanks for doing this! I already reviewed the PR pre-submit, so lgtm but I'd like to get input from other folks. |
CAndC++.md
Outdated
| [LLVM's vector extensions]: http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors | ||
| [GCC's vector extensions]: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html | ||
|
|
||
| Note that inline assembly or other platform-specific features are not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a little confusing, because WebAssembly C/C++ compilers do support some forms of inline assembly. The mental model is that it is platform-specific, because the platform is WebAssembly itself.
|
Thanks, I've revised the text to address the comments. @sunfishcode: That paragraph seemed more relevant to security than nondeterminism, so I moved it over and extended it. Although randomization could be an implementation detail, it is something that developers should at least be aware of and ideally be able to control. |
CAndC++.md
Outdated
|
|
||
| Note that non-WebAssembly inline assembly or platform-specific features | ||
| are not supported, such as x86 assembly or MMX/SSE/NEON vectorization | ||
| primitives. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is, ironically, still slightly misleading, since Emscripten provides <xmmintrin.h> and a few others that provide compatibility with x86-specific APIs, implemented via asm.js SIMD constructs (WebAssembly doesn't yet have SIMD, but it is expected to before long).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, it seems that I should just remove this paragraph.
Security.md
Outdated
| Each WebAssembly module executes within a sandboxed environment separated from | ||
| the host runtime using fault isolation techniques. This implies: | ||
| * Applications execute independently (unless | ||
| [dynamic linking](DynamicLinking.md) is used), and can't escape the sandbox |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applications execute independently even if dynamic linking is used. It's just that an application consists of more than one module. Probably the reference to dynamic linking isn't necessary here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll remove this.
This commit introduces a discussion of WebAssembly's security model for both users and developers, though primarily targeted at latter. Resolves WebAssembly#205.
|
This seems ready to merge, any further comments can be addressed in follow-ups (and @ddcc intends to have follow-ups to this). Will merge soon unless there are any objections. |
This commit introduces a discussion of WebAssembly's security model
for both users and developers, though primarily targeted at latter.
Resolves #205.