New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Comments
tl;dr If your threat model assumes that your adversary can break out of a LXC container, he will also have the ability to break out of VM's.
It was a poor way of explaining. The performance hit is what I laid out clearly in the OP - the lack of hardware GPU acceleration. The, not good, cpu is doing most, perhaps all, of the work. It isn't that kvm takes a performance hit, but that the performance hit comes from lack of hardware video acceleration, which is not usable in kvm.
This is not a rare thing, it is the standard issue with vms without gpu passthrough - which again I note in the OP this laptop is incapable of.
I did not come across this issue when I used to run stuff in vms before simply because I used to do it on my desktop which had a much better cpu, so although it would still be doing all the work it was more capable so didn't notice issues when running videos at least. For games the same issues applied and used passthrough for that, which my desktop does support. I am trying to make the best of this old laptop though!
No intention of buying any other stuff for this. Practical life factors for that. Living in small space where I don't want extra clutter. Not running programs in question much so don't want to invest any money just for this and such. I have the money to buy a 'good' laptop if I wanted. I just don't want.
Old one works fine for everyday tasks, which is mainly cli and light web browsing. I just want a way to squeeze some entertainment out of it now and then (other than porn).
From what I can tell then gvisor feels like a better option for you because gvisor makes gpu passthrough really easy to work with?
Thoughts on gvisor then?
You can use lxc via their container runtime and swap crun or the golang crun equivalent runc iirc and then use gvisor instead so its possible
Huh? I didn't know that? I always thought that vm's are more safer, can you provide me some sources of that?
I used to run unprivileged services in LXC & later LXD - but now use podman containers as they're less maintenance.
Podman is a drop in Docker replacement from Red Hat - it runs "rootless" (unprivileged) out of the box - Docker can run rootless too with some extra steps - but with Docker you have the overhead of an always running daemon.
With podman only the services consume resources. I typically see services use
25-50mbof RAM (seepodman stats) - & it's simple to run containers as a system service with "quadlets"podman top container_namewill show you the user services run as inside the container.Auto updating podman containers is as simple as adding a label to the container. With Docker you have to run extra containers & create systemd timers to keep containers updated.
It is also possible to create extremely locked down containers including running them read-only / dropping all capabilities / prevent privilege escalation / limit resources at a higher level than the container environment:
In the example above the service is effectively running as user
nobodyon bare metal.For something bullet proof you can run the rootless container read-only as an unprivileged (ordinary) user on bare metal - as a different namespaced user inside the container (in it's own separate namespace). If a read-only container needs to write anywhere mount a
tmpfsinside the container (seepodman runman page)An attacker would need to:
Run the container first without dropping any Linux capabilities & check
podman inspect container_nameto see the capabilities it actually needs to run, add them to the quadlet & drop all capabilities.On bare metal the attacker as the unprivileged user (after step 2) cannot alter any container files as they can only be changed by root on bare metal (due to running the container in a different namespace to the unprivileged user which runs the container service)
Create a podman container manually with
podman run& experiment with the various security settings - then usepodletto generate a "quadlet" file to run the container as a systemd service:During testing choose a Docker image with a shell for easier debugging (Alpine Linux based images are usually the most lightweight). Once you have a working configuration switch to an image without a shell available or build your own for an even more difficult container environment to exploit.
Another immutable os choice is opensuse's Micro OS - for a version with a desktop see:
Live images are also available to try it out.
See "Kalpa Desktop" if you prefer XFCE.
All are rolling releases so you never have to reinstall. Disk encryption is very simple & you also have selinux by default.
I switched all my servers from Ubuntu to Micro OS about 2 years ago & they are absolutely maintenance free once configured. If an update fails the previous system snapshot is reverted to.
So far I have had no breakages at all with Tumbleweed based systems (good old German efficiency) - OpenSUSE's security is extremely good, you don't hear much about them as their stuff is practically never exploited.
Using Podman secrets to store 378000 character passwords also works:
Perhaps run something like a Brave Browser container (or one of their other browser images):
With Micro OS on a server and with the updates, are there certain persistent directories i assume for your app stuff or whatever you are hosting?
That's not true. A hypervisor's attack surface is far smaller than a kernel's attack surface, especially with paravirtualization.
gVisor is not a hypervisor so its concept of passthrough (allowing the application to issue syscalls directly to the kernel without going through the memory-safe emulation layer) is different than the virtualization concept of passthrough (remapping all PCIe actions, memories, interrupts, etc. to the guest with an IOMMU).
gVisor is an extremely good way to protect the kernel (and thus prevent an escape) from malicious/compromised code in a Docker container, by far the best, but performance can vary depending on the workload, since it literally re-implements much of the kernel's simpler APIs entirely in Go. Networking, for example, takes a particularly heavy hit.
People never learn. Should have use C

I run all services as podman rootless containers which live under
/home/unprivileged_user:/etccan also be edited - everything else is mostly immutable/& most of/usrexcept/usr/local:I create golden images with all packages / configurations included using:
This creates a Micro OS
isothat installs itself when you boot from it - it takes 5-10 minutes to install a fully configured server.I wrote a "lowend-init" (basically a first boot python script) - that configures the networking / ip addresses from a system's MACs. When I buy a new server I just install Ubuntu & run the "lowend-init" script to print / create an
inifile with ip's / gateways / macs - & rebuild the iso with the newinifile included. I have 40 machines now......so am forced to work more efficiently.The kiwi app can build most distros - not sure if other distro iso's install themselves like Micro OS - it seems a better alternative to ansible for initial configuration at least (although I need to get ansible working too some time for
/etcchanges) - I run my iso build environment in a tumbleweed container with azrambuild volume mounted - a new iso builds in 4-5 minutes on a Ryzen 5950xAnother isolation option:
"The speed of containers, the security of VMs"
Malware sandboxes tend not to be developed with security in mind since they are not meant to be run on systems handling sensitive data, rather undetectability and normal-seeming behavior. If anything, all the complex profiling and observability features they have give them a large attack surface area.
You are not getting it, passthrough is impossible with my hardware.
No software will magically make that possible.
Thanks, not read through the whole reply yet but I have never understood why they created lxd and just confused things. Lxc configuration was straight forward enough already so lxd seemed pointless but the 'trendy' one to use and when I would research for lxc configs I was constantly being tripped up with lxd results.
Oh btw I realised that the vm is not the issue as I suddenly remembered I am not even able to run 720p on the host, due to poor performance, and I have to take web videos down to lower resolutions too. I found the videos in 480p yesterday of the ones I was looking for and running fine on the vm.
I have never been bothered about all the HD crap. I am a 90s kid so low res suits me fine and I only really like those 90s or earlier shows anyway. So low rest would have been the norm then.
HD of those older shows actually looks more strange to me as I expect old school grainyness like with vhs. Yea I know 'grain' is something people deliberately keep even for HD but low res works for me!
The discussion so far is still informative though so don't stop on the above account.
I disagree. Just one example: AFAIK there's no device namespace, so any root user in any namespace can just create device nodes and directly access filesystems on disk and RAM.
If anyone can exploit anything in a container that can lead to a container local root shell (even if that root is mapped to a different UID on the host), they can still access whatever they want.
EDIT: Actually, I just tested that and it's not true. But I still don't trust it enough. VMs all the way for me.
LXD added a REST API for managing containers remotely & made it easy to get a shell in containers / also run qemu vm's / clustering for high availability / HA networking support.
More recently LXD => Incus (LXD forked by it's main developers) ==> Incus OS which looks really interesting:
For LXC / Podman clustering see Hashicorp Nomad.
I still run LXD @ home as it's useful for ad hoc testing of Alpine Linux when testing Alpine Docker images.
As I mentioned, gVisor passthrough is not related to IOMMU passthrough. You don't need DMAR (DMA Remapping, an IOMMU feature that is broken on some systems and not present on very old systems), so it will work. You lose a lot of security by doing that, though, because now you are directly exposing the entire DRM subsystem of the kernel to the application without any sandboxing.
I see. Well if less secure it defeats the purpose then eh? or for my previous mentioned use case would it still be sufficient? I think this machine is pretty much a none starter for anything but very rudimentary gaming, even without vms, so not really any point.
I tried running an open source game from 10 years ago, so no need for any of these tricks, just running natively and it could not handle that either.
On a better machine it would likely support pci passthrough anyway.
Now I have a way to run videos at what I find an acceptable resolution that will suffice for my entertainment on this machine.