Live data from Hacker News

Microsandbox: Virtual Machines that feel and perform like containers

github.com

161–170 of 195 posts

Re: Microsandbox: Virtual Machines that feel and perform like containers

#161

Tangential question: why does it normally take so long to start traditional VMs in the first place? At least on Windows, if you start a traditional VM, it takes several seconds for it to start running anything . Edit: when I say anything , I'm not talking user programs. I mean as in, before even the first instruction of the firmware -- before even the virtual disk file is zeroed out, in cases where it needs to be. Yo…

In Linux, VM memory allocations can be slow if it tries to allocate GBs of RAM using 4K pages. There are ways to help it allocate 1GB at a time which vastly speeds it up. Windows probably has an equivalent.

Is this specifically for during boot time? Also, any links?

Re: Microsandbox: Virtual Machines that feel and perform like containers

#162

Thanks for sharing! I'm the creator of microsandbox. If there is anything you need to know about the project, let me know. This project is meant to make creating microvms from your machine as easy as using Docker containers. Ask me anything.

Think I can build a notebook on top of this ? Jupyter client has been a pain to manage

Re: Microsandbox: Virtual Machines that feel and perform like containers

#163

For my taste, container technology is pushing the OS too far. By typing: mount you immediately see what I mean. Stuff that should be hidden is now in plain sight, and destroys the usefulness of simple system commands. And worse, the user can fiddle with the data structures. It's like giving the user peek and poke commands. The idea of containers is nice, but they are a hack until kernels are re-architected.

Sorry I am lacking the context to understand this post. What does running mount inside a container do that's so egregious? Are host mounts exposed to the container somehow? I thought everything needed to be explicitly passed through to the container (e.g. using a volume)?

I think they mean that running `mount` on the host now lists hundreds of mountpoints from containers, snaps, packagekit etc.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#164
post #86
post #84

Looks great and excited to try this out. We’ve also had success using CodeSandbox SDK and E2B, can you share some thoughts on how you compare or future direction? Do you also use Firecracker under the hood?

I can't tell if it uses firecracker but thats my main question too. I'm curious as to whether microsandbox will be maintained and proper auditing will be done. I welcome alternatives. It's been tough wrestling with Firecracker and OCI images. Kata container is also tough.

I wanted to try Kata containers soon. What difficulties do you have with them?

Re: Microsandbox: Virtual Machines that feel and perform like containers

#165

Thanks for sharing! I'm the creator of microsandbox. If there is anything you need to know about the project, let me know. This project is meant to make creating microvms from your machine as easy as using Docker containers. Ask me anything.

Think I can build a notebook on top of this ? Jupyter client has been a pain to manage

Not sure what that entails. You can try and I can help along the way

Re: Microsandbox: Virtual Machines that feel and perform like containers

#166

Earlier quoted context omitted.

Could you elaborate on how you could secure those architectures better? It's unclear to me how being in device firmware or being a VMM provides you with any further abilities. Surely you still have the same fundamental problem of being a shared resource. Intuitively there are differences. The Linux kernel is fucking huge, and anything that could bake the "shared resources" down to less than the entire kernel would be…

When you escape a container generally you can do whatever the kernel can do. There is no further security boundary. If you escape into a VMM you can do whatever the VMM can do. You can build a system where it can not do very much more than the VM guest itself. By the time the guest boots the process containing the vCPU threads has already lost all its interesting privileges and has no credentials of value. Similar wi…

> It's just that isn't a path with any next steps in the real world.

It appears we find ourselves at the Theory/Praxis intersection once again.

> The road from Docker to a secure VM platform is rich with reasonable incremental steps forward

The reason it seems so reasonable is that it's well trodden. There were an infinity of VM platforms before Docker, and they were all discarded for pretty well known engineering reasons mostly to do with performance, but also for being difficult for developers to reason about. I have no doubt that there's still dialogue worth having between those two approaches, but cgroups isn't a "failed" VM security boundary anymore than Linux is a failed micro kernel. It never aimed to be a VM-like security boundary.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#167

Earlier quoted context omitted.

> silicon support for nested virtualization Is there any guarantee that this "silicon support" is any safer than the software? Once we break the software abstraction down far enough it's all just configuring hardware. Conversely, once you start baking significant complexity into hardware (such as strong security boundaries) it would seem like hardware would be subject to exactly the same bugs as software would, excep…

> Is there any guarantee that this "silicon support" is any safer than the software? Safety and security claims are only meaningful in the context of threat models. As described in the Xen/uXen/AX video, pKVM and AWS Nitro security talks, one goal is to reduce the size, function and complexity of open-source code running at the highest processor privilege levels [1], minimizing dependency on closed firmware/SMM/Trust…

[deleted]

Re: Microsandbox: Virtual Machines that feel and perform like containers

#169
post #92

Earlier quoted context omitted.

The issue, at least with multitenant workloads, isn't "container vulnerabilities" as such; it's that standard containers are premised on sharing a kernel, which makes every kernel LPE a potential container escape --- there's a long history of those bugs, and they're only rarely flagged as "container escapes"; it's just sort of understood that a kernel LPE is going to break containers.

> it's just sort of understood that a kernel LPE is going to break containers. I think it's generally understood that any sort of kernel LPE can potentially (and therefore is generally considered to) lead to breaking all security boundaries on the local machine, since the kernel contains no internal security boundaries. That includes both containers, but also everything else such a user separation, hardware virtualiz…

A large proportion of LPE vulnerabilities are in the nature of "perform a syscall to pass specially crafted data to the kernel and trigger a kernel bug". For containers, the kernel is the host kernel and now the host is compromised. For VMs, the kernel is the guest kernel and now the guest is compromised, but not the host. That's a much narrower compromise and in security models where root on the guest is already expected to be attacker-controlled, isn't even a vulnerability.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#170

For my taste, container technology is pushing the OS too far. By typing: mount you immediately see what I mean. Stuff that should be hidden is now in plain sight, and destroys the usefulness of simple system commands. And worse, the user can fiddle with the data structures. It's like giving the user peek and poke commands. The idea of containers is nice, but they are a hack until kernels are re-architected.

On recent Linux, try:

    findmnt --real
It's part of linux-utils, so it is generally available wherever have a shell. The legacy tools you have in mind aren't ever going to be changed as you would wish, for reasons.
Post reply on HN