Hacker News Reader

Comment by _wmd | Hacker News Reader

Am I correct in understanding the new environment is built on essentially a ptrace sandbox? How does that impact performance? Is it still single threaded? If you're moved beyond single threads, how does the it cope with security problems endemic to userland sandboxing? (TOCTTOU issues as the 'hypervisor' verifies arguments, etc)

Are you willing to compare your approach to for example Lambda's approach, where the user gets an actual real Linux VM. with zero differences (Work that, incidentally was in part contributed to Linux by Google!), as opposed to a Linux emulator?

View on HN

Hi. I'm the PM at Google Cloud on the Second Generation runtimes.

This is based on gVisor (https://github.com/google/gvisor), but it does not use the ptrace sandboxing that is in the mainline open source project. Our First Generation runtimes (aka nacl) were based on ptrace. In our informal testing we have observed the Second Generation runtimes to be about 20% faster than the First Generation. I don't have benchmarks on how it compares to a raw VM.

These new runtimes are capable of multithreading, so long as the language is capable of it. And you will need to use an instance larger than the default (F1 / B1) to have access to more than one thread.

Two have access to more than one hardware thread or more than one OS thread?

I work on gVisor. gVisor supports concurrent multi-treading, but should not be vulnerable to TOCTTOU, even in ptrace mode. gVisor handles system calls itself, it does not simply verify the args for app system calls and then pass them on to the host. That said, if you find any security issues, please let us know. There is a security email address in the github issue template.

App Engine Flex is a version of App Engine that uses VMs with Linux. You can find a comparison between the standard and flexible environments here:

https://cloud.google.com/appengine/docs/the-appengine-enviro...

gVisor can use KVM for isolation instead of ptrace, and I would guess that Google is using it.

Correct. We do not use ptrace in production.

Thanks for clarifying.. it sounds thoroughly tragic, and the kind of endemic overengineering that made so many people (myself included) run screaming from the original App Engine over the years. I guess GCP really turned a page in Google culture and learned to finally listen to customers

AWS> we put your code in a container, like everyone else puts your code in a container. We bikeshedded the Linux distro a bit, so you might need to recompile

Customer> OK. Fine

GCP> our web scale open source userland kernel hypervisor written in Go hosts your code in a Linux-but-not-quite-Linux microservice

Customer> Why does <X> system call return a strange error code?

GCP> You're too dumb to understand. Trust us

Customer> oh, I think I understand well enough. Calls back Azure sales rep

Reply on news.ycombinator.com