paulfurtado

Yes, exactly. And even do things like inject virtual USB drives so you can reinstall an OS or something

Fwiw, if performance isn't paramount, you can have a lot of fun with LKL (linux kernel library) and UML (user mode Linux).

UML is full Linux running as a userspace process. Tools like guestfish use it to modify disk images. UML can only run on Linux though.

LKL lets you use the linux kernel as a library. However, only single threaded. But this allows you to use linux's tcp stack from userspace, or its filesystems, etc. LKL also works on non Linux platforms.

These are definitely a different shape than what you're looking for, but they could help you keep the real linux implementations alive from userspace far into the future.

There are really two types of KVMs... classic ones were used by consumers to plug multiple computers into one screen, keyboard, and mouse and flip back and forth between them.

Networked KVMs let you remotely access a computer or server. It's like VNC except by physically plugging into the ports. This is useful because it allows you to have remote access to a server when its OS is offline, tweak bios settings, watch it boot, reinstall the OS, etc.

Most true servers have this functionality and more built in (ipmi, idrac, redfish, etc are terminology for the feature). These plugin ones allow you to add that functionality to any machine. You're not likely to see tons of them in an actual data center, but they are incredibly useful for systems without remote management built in.

It is great for isolation. There are so many VM based containerization solutions at this point, like Kata Containers, gvisor, and Firecracker. With kata, your kubernetes pods run in isolated VMs. It also opens the door for live migration of apps between ec2 instances, making some kinds of maintenance easier when you have persistent workloads. Even if not for security, there are so many ways a workload can break a machine such that you need to reboot or replace (like detaching an ebs volume with a mounted xfs filesystem at the wrong moment).

The place I've probably wanted it the most though is in CI/CD systems: it's always been annoying to build and test system images in EC2 in a generic way.

It also allows for running other third party appliances unmodified in EC2.

But also, almost every other execution environment offers this: GCP, VMWare, KVM, etc, so it's frustrating that EC2 has only offered it on their bare metal instance types. When ec2 was using xen 10+ years ago, it made sense, but they've been on kvm since the inception of nitro.

The benefit of docker for home assistant is the packaging of it, rather than isolation. You can always run a container with host network mode and privileged mode so that it can access everything it needs to the same as if it were running directly on the host.

I used the VLAN "trick" for connecting my cable modem to my router for a few years in an old multi-floor apartment with pre-wired ethernet, but it's not ideal because the router is then not able to detect the link state of the modem. For example, if you unplug a cable modem and plug it back in, normally the link would go down on the router and then come back up, and when the link returns the router will attempt to fetch a new DHCP lease.

If you have a static IP, it should be fine, but this became an annoyance the couple of times the IP changed when I was living there.

This is of course not the purpose of your post, but since you're interested in this topic, I wanted to mention that you can now create memory-backed files on linux using the memfd_create syscall without using any filesystem (nor unlink) and you can also execute them without the /proc/self/fd trick by using the execveat syscall. In glibc, there is fexecve which uses execveat or falls back to the /proc trick on older kernels.

Do you have any references to specific bugs here? We depend pretty heavily on containers and I'd love to look into these and see if we are impacted and whether we should carry these patches

FWIW on AWS, all nitro instance types can boot as UEFI if the AMI has itself set to use UEFI and all arm64 instances only support UEFI. So if you stick to modern instance types, you can happily use UEFI in AWS.

GCP looks like it does UEFI too. And Azure Gen2 instances use UEFI too.

memfd is a tmpfs file descriptor, but does not use any mounted tmpfs filesystem. It works no matter what filesystems are mounted or access you have.

It's truly great for situations where APIs refuse to take anything other than files and you don't worry about cleanup. Ex: loading certs from memory into a python openssl context.

If the goal of the test is to debug a sad linux server, containers are going to severely limit what ways the server can be sad in, isn't it?

User namespaces have resulted in multiple new container breakout CVEs in the last year. Some guides actually recommend disabling user namespaces because they are still somewhat new and perilous.

If you use cri-o as the runtime along with an openshift container registry, it will actually verify signatures at the runtime layer. In addition to crio, podman and anything based on containers/image supports this too.

Really that just means a registry that sends back a header indicating it supports signatures and serves up the right signature endpoints. It's shocking this isn't more common.

But if you just want to check signatures at the cluster's point of entry, you can use an admission controller to block the pods from being created with unsigned images.