4 ms·

Of course a language-specific sandbox with a highly restricted domain-specific API will be faster than an OS container or VM. The tradeoff is that it can run le

by zapita 8y ago

Of course a language-specific sandbox with a highly restricted domain-specific API will be faster than an OS container or VM. The tradeoff is that it can run less applications unmodified, so less people can use it. I think Cloudflare workers are a cool implementation of domain-specific scripting. I’ve used it and it’s great. And with their scale I’m sure they’ll advance the state of the art in various ways. But there’s no radically new insight here.

madmax96 8y ago
Isn't the point of running these serverless components on data-centers closer to the edge to reduce latency in emerging IoT applications? My question is why would I want to run an unmodified application on this? Because of existing business logic in the form of shared libraries that I'd like to leverage, unmodified?
- davemp 8y ago
  > My question is why would I want to run an unmodified application on this? Complete straw-man here, but this is what I envision: Ignorant businessmen buys a new silver bullet from a (potentially ignorant or malicious) salesperson or idea broker then wants you to "make it work" on the "serverless cloud". Most B2B software provides no reasonable method of determining if their product(s) actually work. So changing the amalgamation of your boss's silver bullets (your business application) requires the rebuilding of a hard won set of folk knowledge. This task is terrifying, unproductive, potentially impossible (non-permissive licenses), and something that most developers in this situation would like to avoid. Of course there are decent ways to avoid and/or address situations like the one described, but this seems close to what I've witnessed in industry.
  - mlthoughts2018 8y ago
    I actually have experienced basically the opposite sort of thing. There are monolothic applications and overly restrictive central IT processes where the “folk knowledge” you describe is basically a job-security obfuscation tactic for developers to wield political control and act as credit-mongering constraints on what other developer teams might want to do, under the guise of it all being for the safety or stability of the monoliths (which are already unstable and unsafe). Particularly in cases where multiplicity of different runtime environments is critical for innovation, this central IT bureaucracy can be totally killer. The worst is when outside consultants come in and just reinforce what the central IT people are already stonewalling with. For this reason, it can actually be great when new silver bullets come in from consultants who are able to break that hegemony. Sure, the silver bullets are dipshitty business crap, but if it at least offers a hook for using better modern tooling, you can successfully not die from the central IT crap. Then by showing the results of the new tools, you can undermine the “folk knowledge” gate keeper people, and force them to be honest about the declining business value of protecting the so-called stable legacy monoliths.
nickpsecurity 8y ago
Yeah, there's a ton of them in the literature. Anything enforcing memory safety (eg Softbound+CETS or SAFEcode), control-flow integrity (esp Code-Pointer Integrity w/ segments), data-flow integrity, information-flow control, etc might be useful to build on here. Many are designed for C, too, which is closer to metal than Javascript, has tons of automated checkers (eg RV-Match from RVI), and a certifying compiler (CompCert). The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. The MMU can isolate what we call known unknowns where something goes wrong (eg bitflip or RAM decay on protection mechanism), the app goes rogue, and it's still contained a bit. That's why the strongest approach from high-assurance security is still separation kernels: microkernels designed specifically for security that fit into L1 caches, are often mathematically verified in some way, support individual apps running in own address space optionally on a language runtime, and support VM's for legacy apps. Muen is an example of that approach for x86, seL4 an example for ARM (mainly ARM), and INTEGRITY-178B a commercial example for PPC (beware marketing hype): https://muen.sk/ https://muen.sk/ https://sel4.systems/ https://sel4.systems/ https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17...
- stcredzero 8y ago
  The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. Just because one abstracts-away the sandbox from the users doesn't mean that the sandbox can't be used as a layer of protection. The wiser approach would be to use an additional layer, though it's abstracted away from the user's point of view.
  - nickpsecurity 8y ago
    I agree. Im just emphasizing it since many people think safe languages can be enough security because the forget attacks that break abstraction gaps. One benefit of Spectre/Meltdown and Rowhammer was helping me counter that more easily. :)
writepub 8y ago
With the advent of WASM, the mentioned sandbox is no more language specific. Threads & garbage collection are coming soon to WASM, which should open up most relevant languages in use today to this more efficient sandbox
- zapita 8y ago
  I agree, wasm is a notable step forward. But it's not magical either. For example you still need to expose system functionality to the application. That means either exposing existing OS APIs (which gives you compatibility at the cost of security and speed); or defining new APIs which take advantage of the properties of wasm (better security and speed; worse compatibility). As far as I can tell, the wasm community is still primarily focused on running in the browser. There is an explicit goal of supporting "non-web" targets, but no consensus on how to expose system APIs, let alone a full implementation.
- ori_b 8y ago
  > With the advent of WASM, the mentioned sandbox is no more language specific. Which removes many of the advantages.
  - MrEldritch 8y ago
    How do you figure?
    - skybrian 8y ago
      One issue might be that Cloudflare won't have the source and can't recompile the code. But perhaps web assembly is easy enough to decompile?
      - vnorilo 8y ago
        wasm doesn't as of now have any means of code generation independent from the JS api. There is also no way to obfuscate call targets or corrupt heap outside the module's linear memory. Any sandbox breaking bugs that do not involve JS would be codegen errors, AFAICT; in that case what you need to analyze is just the wasm blob and its interaction with the codegen pipeline.
zackbloom 8y ago
The real hope is people start building applications this way. That's the innovation. The current serverless technologies they are using provide process level APIs which are fundamentally unnecessary for their application, and when you break free of that things change dramatically.

by zapita 8y ago

madmax96 8y ago

Isn't the point of running these serverless components on data-centers closer to the edge to reduce latency in emerging IoT applications? My question is why would I want to run an unmodified application on this? Because of existing business logic in the form of shared libraries that I'd like to leverage, unmodified?

davemp 8y ago
> My question is why would I want to run an unmodified application on this? Complete straw-man here, but this is what I envision: Ignorant businessmen buys a new silver bullet from a (potentially ignorant or malicious) salesperson or idea broker then wants you to "make it work" on the "serverless cloud". Most B2B software provides no reasonable method of determining if their product(s) actually work. So changing the amalgamation of your boss's silver bullets (your business application) requires the rebuilding of a hard won set of folk knowledge. This task is terrifying, unproductive, potentially impossible (non-permissive licenses), and something that most developers in this situation would like to avoid. Of course there are decent ways to avoid and/or address situations like the one described, but this seems close to what I've witnessed in industry.
- mlthoughts2018 8y ago
  I actually have experienced basically the opposite sort of thing. There are monolothic applications and overly restrictive central IT processes where the “folk knowledge” you describe is basically a job-security obfuscation tactic for developers to wield political control and act as credit-mongering constraints on what other developer teams might want to do, under the guise of it all being for the safety or stability of the monoliths (which are already unstable and unsafe). Particularly in cases where multiplicity of different runtime environments is critical for innovation, this central IT bureaucracy can be totally killer. The worst is when outside consultants come in and just reinforce what the central IT people are already stonewalling with. For this reason, it can actually be great when new silver bullets come in from consultants who are able to break that hegemony. Sure, the silver bullets are dipshitty business crap, but if it at least offers a hook for using better modern tooling, you can successfully not die from the central IT crap. Then by showing the results of the new tools, you can undermine the “folk knowledge” gate keeper people, and force them to be honest about the declining business value of protecting the so-called stable legacy monoliths.

nickpsecurity 8y ago

Yeah, there's a ton of them in the literature. Anything enforcing memory safety (eg Softbound+CETS or SAFEcode), control-flow integrity (esp Code-Pointer Integrity w/ segments), data-flow integrity, information-flow control, etc might be useful to build on here. Many are designed for C, too, which is closer to metal than Javascript, has tons of automated checkers (eg RV-Match from RVI), and a certifying compiler (CompCert). The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. The MMU can isolate what we call known unknowns where something goes wrong (eg bitflip or RAM decay on protection mechanism), the app goes rogue, and it's still contained a bit. That's why the strongest approach from high-assurance security is still separation kernels: microkernels designed specifically for security that fit into L1 caches, are often mathematically verified in some way, support individual apps running in own address space optionally on a language runtime, and support VM's for legacy apps. Muen is an example of that approach for x86, seL4 an example for ARM (mainly ARM), and INTEGRITY-178B a commercial example for PPC (beware marketing hype): https://muen.sk/ https://muen.sk/ https://sel4.systems/ https://sel4.systems/ https://www.ghs.com/products/safety_critical/integrity-do-178b.html https://www.ghs.com/products/safety_critical/integrity-do-17...

stcredzero 8y ago
The other drawback is you have less layers of protection if operating in process with language-based and/or tactical mitigations. Just because one abstracts-away the sandbox from the users doesn't mean that the sandbox can't be used as a layer of protection. The wiser approach would be to use an additional layer, though it's abstracted away from the user's point of view.
- nickpsecurity 8y ago
  I agree. Im just emphasizing it since many people think safe languages can be enough security because the forget attacks that break abstraction gaps. One benefit of Spectre/Meltdown and Rowhammer was helping me counter that more easily. :)

writepub 8y ago

With the advent of WASM, the mentioned sandbox is no more language specific. Threads & garbage collection are coming soon to WASM, which should open up most relevant languages in use today to this more efficient sandbox

zapita 8y ago
I agree, wasm is a notable step forward. But it's not magical either. For example you still need to expose system functionality to the application. That means either exposing existing OS APIs (which gives you compatibility at the cost of security and speed); or defining new APIs which take advantage of the properties of wasm (better security and speed; worse compatibility). As far as I can tell, the wasm community is still primarily focused on running in the browser. There is an explicit goal of supporting "non-web" targets, but no consensus on how to expose system APIs, let alone a full implementation.
ori_b 8y ago
> With the advent of WASM, the mentioned sandbox is no more language specific. Which removes many of the advantages.
- MrEldritch 8y ago
  How do you figure?
  - skybrian 8y ago
    One issue might be that Cloudflare won't have the source and can't recompile the code. But perhaps web assembly is easy enough to decompile?
    - vnorilo 8y ago
      wasm doesn't as of now have any means of code generation independent from the JS api. There is also no way to obfuscate call targets or corrupt heap outside the module's linear memory. Any sandbox breaking bugs that do not involve JS would be codegen errors, AFAICT; in that case what you need to analyze is just the wasm blob and its interaction with the codegen pipeline.

zackbloom 8y ago

The real hope is people start building applications this way. That's the innovation. The current serverless technologies they are using provide process level APIs which are fundamentally unnecessary for their application, and when you break free of that things change dramatically.