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

Hardening Drupal with WebAssembly

wasmlabs.dev

Post reply on HN
Print view View original

21–30 of 52 posts

Re: Hardening Drupal with WebAssembly

#21

Post by garganzol »

Ok, considering that it comes from VMware, I think they aim to create some kind of a multi-architectural execution environment that can host apps in a hardware-independent way on multiple clustered nodes.

I applaud this development but at the same time any kind of run-time code translation imposes performance penalties. WASM is not exception. It would be enlightening to hear the authors' stance on this topic. CPU utilization factor is a big thing for hosting companies, so they will be hesitant to use something like this in production.

Re: Hardening Drupal with WebAssembly

#22

Post by giancarlostoro »

garganzol wrote: post #21

Ok, considering that it comes from VMware, I think they aim to create some kind of a multi-architectural execution environment that can host apps in a hardware-independent way on multiple clustered nodes. I applaud this development but at the same time any kind of run-time code translation imposes performance penalties. WASM is not exception. It would be enlightening to hear the authors' stance on this topic. CPU uti…

So a GraalVM competitor but on WASM.

I do want to see the WASM ecosystem grow and thrive, but it will take some time, although what I have seen so far is amazing. I am most excited for WASI. Havent checked up on it in a moment but its basically the WebAssembly version of nodejs but as a spec anyone implementing a WASM runtime can support, so there will be various options to run your code ultimately.

Re: Hardening Drupal with WebAssembly

#23

Post by garganzol »

giancarlostoro wrote: post #22
garganzol wrote: post #21

Ok, considering that it comes from VMware, I think they aim to create some kind of a multi-architectural execution environment that can host apps in a hardware-independent way on multiple clustered nodes. I applaud this development but at the same time any kind of run-time code translation imposes performance penalties. WASM is not exception. It would be enlightening to hear the authors' stance on this topic. CPU uti…

So a GraalVM competitor but on WASM. I do want to see the WASM ecosystem grow and thrive, but it will take some time, although what I have seen so far is amazing. I am most excited for WASI. Havent checked up on it in a moment but its basically the WebAssembly version of nodejs but as a spec anyone implementing a WASM runtime can support, so there will be various options to run your code ultimately.

Yes, I agree on WASM versatility, but: when I use my Mac M1 (with ARM64 processor) and try to run a x64 based executable, there is a small but noticeable lag on the app's start. It is caused by the dynamic instruction translation, essentially by JITting x64 code to ARM64 instruction set on the fly.

While the lag is small, it is unpleasant enough to make my work less comfortable when compared to the native ARM64 images.

The story repeats itself with Windows 11 ARM64 - it can run x86 and x64 images but there is a price to pay - they are not as snappy as native ARM64 images due to the dynamic translation costs.

Having a WASM on board poses the same kind of dilemma which directly impacts hosting bills.

Re: Hardening Drupal with WebAssembly

#24

Post by angelmm »

garganzol wrote: post #18

I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI. I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime l…

Wasm Labs dev here :)

In mod_wasm, there are some differences with a pure CGI implementation. When Apache boots, it loads the configuration and initializes the WasmVM. When a new HTTP request arrives, the VM is ready so you don't need to initialize a different process to manage it.

You still need to process the request and pass the data to the Wasm module. This step is done via STDIN through the WebAssembly System Interface (WASI) implementation [0]. The same happens in the opposite direction, as the module returns the data via STDOUT.

So, the CGI pattern is still there, but it doesn't require new processes and all the code runs in a sandbox.

However this is not the only way you can run a Wasm module. In this specific case, we use CGI via WASI. In other cases, you may compile a module to fulfill a specific API, like ProxyWasm [1] to create HTTP filters for proxies like Envoy.

- [0] https://wasi.dev/

- [1] https://github.com/proxy-wasm/spec

Re: Hardening Drupal with WebAssembly

#25

Post by ereslibre »

garganzol wrote: post #18

I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI. I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime l…

> I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth.

(Wasm Labs dev here) We haven't yet measured performance in a meaningful way that we can use to compare, mainly because our PHP builds also have certain limitations mentioned in the article, such as not having OPcache available at PHP. It is however an iterative process, and we are interested in this, as well as we understand that it's interesting for the community.

> Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime library initialization. Does it work any differently when it comes to WASM?

It's a little different in Wasm, in the sense that there is no need to fork/exec (if talking about bare CGI). The PHP executable gets loaded into the runtime once (what will compile it from Wasm -> native ISA), and then for every request we create a Wasm execution context, and run the PHP Wasm module that interprets the PHP script.

Creating a Wasm execution context is certainly much lighter than a fully fledged fork/exec.

Re: Hardening Drupal with WebAssembly

#26

Post by garganzol »

angelmm wrote: post #24
garganzol wrote: post #18

I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI. I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime l…

Wasm Labs dev here :) In mod_wasm, there are some differences with a pure CGI implementation. When Apache boots, it loads the configuration and initializes the WasmVM. When a new HTTP request arrives, the VM is ready so you don't need to initialize a different process to manage it. You still need to process the request and pass the data to the Wasm module. This step is done via STDIN through the WebAssembly System In…

> when a new HTTP request arrives, the VM is ready so you don't need to initialize a different process to manage it.

I suspected that, pretty smart. I presume that a WASM module state can be cached in a similar way, essentially imitating a "fork" syscall semantics while keeping the pool of request handlers in a always-ready hot state.

Re: Hardening Drupal with WebAssembly

#27

Post by nobleach »

PrimeMcFly wrote: post #9

The article claims NASA use Drupal, which was quick to verify as true, but NASA also uses Django, or at least the Django project still claims they do. Why on earth are they using both?

For the same reason almost ALL old companies that have existed in the tech sector for more than 20 years use more than one language/framework/programming practice/etc... Things grow, things get acquired, things languish.

Re: Hardening Drupal with WebAssembly

#28

Post by jeroenhd »

I don't see a breakdown of the costs of this layer of hardening. There's nothing on performance, memory usage, library and database support, and so on. Just a few modules that don't work optimally, noticeably the OpCode cache that speeds up PHP quite significantly.

Just stuffing something in a sandbox is easy. Set up a VM and don't add a network card and you've got a near perfect sandbox without any performance overhead. Maybe even do so for each request through Firecracker if you fear memory persistence. What matters is all the added complexity and the downsides of each solution.

Without any comparison, this attempted sales pitch for WASM is little more than a showcase, like when someone runs WINE in the browser.

Re: Hardening Drupal with WebAssembly

#29

Post by the-dude »

QuiDortDine wrote: post #20

I used to work with Drupal, it was a security nightmare, like almost all community-based extension system (see also npm). Modules made Drupal popular, they also made it close to impossible to have any sense of security, as only very popular modules would be audited, and you basically needed a panoply of smaller ones depending on your use case. I wonder if that's changed over time, for instance I could see GPT3.5 doin…

Is there already a law in place, or are we supposed to use Godwin's?

Re: Hardening Drupal with WebAssembly

#30

Post by ridruejo »

jeroenhd wrote: post #28

I don't see a breakdown of the costs of this layer of hardening. There's nothing on performance, memory usage, library and database support, and so on. Just a few modules that don't work optimally, noticeably the OpCode cache that speeds up PHP quite significantly. Just stuffing something in a sandbox is easy. Set up a VM and don't add a network card and you've got a near perfect sandbox without any performance overh…

You are completely correct. These are just the early steps to get it into people's radars. We follow the Unix approach of "Make it work, make it right, make it fast". We are on the "make it work" step and moving to "make it right", for which we will focus to run as many unmodified applications as possible. This requires better support for PHP features that still depend on WebAssembly-related features that are not fully baked yet (ie threading, WASI preview 2) as well as adding over the network database support (ie MySQL) since most apps don't use SQLite in production.

Once all that is in place, you can move into the "make it fast" part, but for many scenarios where security is an issue (high profile websites) even a significant performance penalty (that can be offset with beefier hardware or caching) may be desirable.

Post reply on HN