AWS Lambda is appealing as it would allow to drive costs down and enable auto scaling without any effort on my part. Last but not least, it supports b

On running untrusted code in AWS Lambda

submited by

Style Pass

2022-06-22 23:30:03

AWS Lambda is appealing as it would allow to drive costs down and enable auto scaling without any effort on my part. Last but not least, it supports both amd64 and aarch64!

Sandboxing is a must. Even though it is presumably possible to isolate a Lambda function from the rest of the infrastructure, an exploit could leave it in a weird state. This is concerning as Lambdas are reused if requests come in a short succession.

As KVM is not available, we are running in dynamic binary translation mode. Unlike KVM-based virtualiser, it didn't undergo security audit and is not recommended. Probably still fine for a low-profile project.

QEMU can virtualise the whole system or a single user-space process. The later is utterly insecure therefore we went for a whole system virtualisation. Here's some timing data.

The only working approach to sandboxing untrusted code in AWS Lambda was QEMU. The overall slowdown compared to running unsandboxed was in the range of 22-66. This is absolutely unacceptable as instant response would've been replaced with staring at a spinning wheel. I strongly believe that being blazingly fast is the important feature of luajit.me.