Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Shopify Uses WebAssembly Outside of the Browser

shopify.engineering

Post reply on HN
Print view View original

121–130 of 135 posts

Re: How Shopify Uses WebAssembly Outside of the Browser

#121

Post by CyberRabbi »

eloff wrote: post #118
CyberRabbi wrote: post #110

Earlier quoted context omitted.

Whether or not people who likely have no actual experience in this space dislike what I’m saying about the pointlessness of using wasm for this use case has no bearing on my correctness. Most of them demonstrated they didn’t know the difference between seccomp and seccomp-bpf and there have been no rational counter arguments that hold their weight. Usually downvotes without rational rebuttals are a sign of the OP’s c…

I mention the downvotes because when you find yourself thinking you're right and everyone is wrong usually it's you that's mistaken. In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one. Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do…

There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf.

Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.

Re: How Shopify Uses WebAssembly Outside of the Browser

#122

Post by devwastaken »

CyberRabbi wrote: post #22
devwastaken wrote: post #19

Earlier quoted context omitted.

That's a pretty bold statement. I'd like to see an in depth analysis between the two before supporting that.

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.

"readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface.

The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not much actual security analysis of existing runtimes - but there are good reasons for why it can be viewed as more secure.

Re: How Shopify Uses WebAssembly Outside of the Browser

#123

Post by eloff »

CyberRabbi wrote: post #121
eloff wrote: post #118

Earlier quoted context omitted.

I mention the downvotes because when you find yourself thinking you're right and everyone is wrong usually it's you that's mistaken. In this case anyone with experience in computer security can tell you multiple layers of defense are always better than one. Seccomp is great, and I think you actually have a point about it, but it's hard to get right without locking out all system calls entirely - and that's hard to do…

There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf. Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.

You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible.

The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing seccomp-bpf and now the burden is on you to provide enough functionality to run something without also providing so much to allow a sandbox escape.

Re: How Shopify Uses WebAssembly Outside of the Browser

#124

Post by CyberRabbi »

devwastaken wrote: post #122
CyberRabbi wrote: post #22

Earlier quoted context omitted.

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.

"readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not…

Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).

Re: How Shopify Uses WebAssembly Outside of the Browser

#125

Post by CyberRabbi »

eloff wrote: post #123
CyberRabbi wrote: post #121

Earlier quoted context omitted.

There’s no need for me to guess if I’m wrong or not, prove to me that I’m wrong. Thus far most replies have confused seccomp for seccomp-bpf. Seccomp locks out every system call except for read, write, exit, and sigreturn. That’s why the extra defense afforded by wasm is superfluous here.

You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible. The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing secco…

Are you serious? You just allocate a large section of virtual memory before entering seccomp mode. This is not hard. I have used seccomp in production myself.

Not to mention sandboxed wasm is similarly restrictive and you need third-party library support to operate in that “embedded” environment. You don’t just get a normal runtime environment for free. Wasm simply gets you memory “bounds checks” but it’s not necessary if the isolate owns the entire process, as in the seccomp model.

Re: How Shopify Uses WebAssembly Outside of the Browser

#126

Post by eloff »

CyberRabbi wrote: post #125
eloff wrote: post #123

Earlier quoted context omitted.

You're totally ignoring the parts I called you out on, which I'm tempted to view as a tacit admission you see your position there as indefensible. The trouble is you can't run much in that environment - not even mmap or sbrk to allocate heap memory. It's basically embedded C without even malloc. In reality WASM is a more practical target because many high level languages can compile to it. Or you end up needing secco…

Are you serious? You just allocate a large section of virtual memory before entering seccomp mode. This is not hard. I have used seccomp in production myself. Not to mention sandboxed wasm is similarly restrictive and you need third-party library support to operate in that “embedded” environment. You don’t just get a normal runtime environment for free. Wasm simply gets you memory “bounds checks” but it’s not necessa…

Are you serious? You want to ask partners to write embedded C programs using a pre allocated virtual memory range?

It's obvious why they went for WASM instead.

Re: How Shopify Uses WebAssembly Outside of the Browser

#127

Post by atrandom »

twic wrote: post #56

So how about garbage collection? WASM doesn't have GC in the machine model, right? So either customers have to use a language with manual memory management, which is hard work, or use one with GC and then compile the collector into their binaries, which means bloat, and possibly a sub-par GC. I guess what I'm saying is that it seems like it would have been better to have used a JVM.

It looks like AssmeblyScript has GC already https://www.assemblyscript.org/runtime.html

Re: How Shopify Uses WebAssembly Outside of the Browser

#128

Post by CyberRabbi »

eloff wrote: post #126
CyberRabbi wrote: post #125

Earlier quoted context omitted.

Are you serious? You just allocate a large section of virtual memory before entering seccomp mode. This is not hard. I have used seccomp in production myself. Not to mention sandboxed wasm is similarly restrictive and you need third-party library support to operate in that “embedded” environment. You don’t just get a normal runtime environment for free. Wasm simply gets you memory “bounds checks” but it’s not necessa…

Are you serious? You want to ask partners to write embedded C programs using a pre allocated virtual memory range? It's obvious why they went for WASM instead.

My point was exactly that you don’t necessarily write your code for an embedded environment in the seccomp model. You provide code in a dynamic library format and the normal dynamic linker links the necessary calls (e.g. malloc) at runtime, exactly as a wasm would provide that environment (via WASI or whatever). Since those calls are all only implemented in terms of write,read,exit,and sigreturn you are guaranteed a high level of security.

Wasm is no different in this regard. You don’t get libc for free with wasm. The only thing you get with a wasm format is memory bounds checking but again that isn’t necessary in the seccomp model.

Re: How Shopify Uses WebAssembly Outside of the Browser

#129

Post by enos_feedler »

mekkkkkk wrote: post #109
enos_feedler wrote: post #94

Earlier quoted context omitted.

Yes, funny ecosystem and unpredictable because smart people contribute innovative and interesting things. This is the best feature of an open, truly shared ecosystem. Everyone owns it and feel safe contributing to it. The web rules!

I wish I could share your enthusiasm. Good on you. To me the web of today is an ever-expanding ball of shit being rolled in different directions by giant corporations. I agree it's fun to work with, but it isn't healthy.

I agree with your take on the web today. I am trying to do my part to promote the things outside that bubble. I thought this was a good place to do that :)

Re: How Shopify Uses WebAssembly Outside of the Browser

#130

Post by mirekrusin »

pangoraw wrote: post #85
xg15 wrote: post #6

Earlier quoted context omitted.

Pro: You don't need server infrastructure to customise a Shopify flow. Con: You need coders knowledgeable in WASM. However, I could imagine that an ecosystem of "plugins" could emerge, i.e. ready-made WASM apps that merchants could plug into their stores. There might be more security issues though, if the developer of the WASM and the merchant using it aren't the same party. I think it will be interesting to see how…

I think it is why they have gone with AssemblyScript as the main supported language. Since it is similar to Typescript, Web developers will likely have a easier time learning it.

It’s mainly about the runtime (lack of it) that language brings, ie. garbage collected language brings garbage collector runtime with it that has to be included with every binary. Even rust and c have (relatively thin) runtimes. AssemblyScript has optional/controllable very thin runtime.

What their decision means in practice is that you can execute any language if you want but they won’t expose any specific runtimes to thin your binary. They will also actively support workflows based on AssemblyScript.

Post reply on HN