[lambdanodecore]

Basically any open source project nowadays run their software stack in containers often requiring docker compose. Unfortunatley Smol machines do not support Docker inside the microvms and they also do not support nested VMs for things that use Vagrant. I think this is a big drawback.

[binsquare]

I can support docker - will ship a compatible kernel with the necessary flags in the next release.

[lambdanodecore]

I tried something like this already, also including nested kvm. I think this will increase the boot time quiet a bit.

Also libkrun is not secure by default. From their README.md:

> The libkrun security model is primarily defined by the consideration that both the guest and the VMM pertain to the same security context. For many operations, the VMM acts as a proxy for the guest within the host. Host resources that are accessible to the VMM can potentially be accessed by the guest through it.

> While defining the security implementation of your environment, you should think about the guest and the VMM as a single entity. To prevent the guest from accessing host's resources, you need to use the host's OS security features to run the VMM inside an isolated context. On Linux, the primary mechanism to be used for this purpose is namespaces. Single-user systems may have a more relaxed security policy and just ensure the VMM runs with a particular UID/GID.

> While most virtio devices allow the guest to access resources from the host, two of them require special consideration when used: virtio-fs and virtio-vsock+TSI.

> When exposing a directory in a filesystem from the host to the guest through virtio-fs devices configured with krun_set_root and/or krun_add_virtiofs, libkrun does not provide any protection against the guest attempting to access other directories in the same filesystem, or even other filesystems in the host.

[fqiao]

Thanks so much for the feedbacks. Yes these are valid concerns around libkrun security, We are planning and developing features around them actually, and hopefully that could alleviate the conerns.

for virtio-fs, yes the risk of exposing the host fs struture exists, and we plan to:

1. creating staging directory for each vm and bind-mount the host dir onto them

2. having private mount namespaces for vms

they are both tracked in our github issues:

https://github.com/smol-machines/smolvm/issues/152 https://github.com/smol-machines/smolvm/issues/151

2 may need much more efforts than we imagine, but we will ensure to call this out in our doc.

For the concern around TSI, we are developing virtio-net in-parallel, it is also tracked in our github and will be released soon: https://github.com/smol-machines/smolvm/issues/91

Would like to collect mroe suggestions on how to make this safer. Thanks!

[binsquare]

Security is a broad topic.

Here's how my perspective:

smolvm operates on the same shared responsibility model as other virtual machines.

VM provides VM-level isolation.

If the user mounts a directory with the capability of symlinks or a host OS with a path for guest software that is designed to escape - that is the responsibility of the user rather than the VM.

Security is not guaranteed by using a specific piece of software, it's a process that requires different pieces for different situations. smolvm can be a part of that process.

[genxy]

So Vagrant is launching the VM locally, is that why it needs nesting?

Would you be ok with a trampoline that launched the VM as a sibling to the Vagrant VM?