gVisor is still pretty useful for untrusted workloads when you don't have KVM, though it gets harder to integrate into workflows where people are running macOS/windows locally
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated:
https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
Alright does this also mean we are detaching some of the google specific stuff and or are more accepting of open standards related changes?
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
I like gvisor but I fear this is too little, too late. Microvms are crushing it right now. I believe even Modal, which is one of the few non-Google users deploying gvisor commercially, and heavily called out in TFA, are moving off gvisor in favor of microvms. Unreal!
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.
gVisor is still pretty useful for untrusted workloads when you don't have KVM, though it gets harder to integrate into workflows where people are running macOS/windows locally
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated: https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
Alright does this also mean we are detaching some of the google specific stuff and or are more accepting of open standards related changes?
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
I like gvisor but I fear this is too little, too late. Microvms are crushing it right now. I believe even Modal, which is one of the few non-Google users deploying gvisor commercially, and heavily called out in TFA, are moving off gvisor in favor of microvms. Unreal!
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.
The networking stack is actually used by many open source project such as tailscale
Hope this shift will make the project get sustainable and evolve fast