Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Do lxc containers protect against malware to a similar level as vms?

2»

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.

  • user3028938user3028938 Member
    edited January 21

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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).

  • @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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

  • @SlowDD said:
    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.

    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-50mb of RAM (see podman stats) - & it's simple to run containers as a system service with "quadlets"

    podman top container_name will 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:

    User=10000
    AutoUpdate=registry
    PodmanArgs=--cpus 0.5 --memory 128m
    PidsLimit=50
    DropCapability=ALL
    NoNewPrivileges=true
    

    In the example above the service is effectively running as user nobody on 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 tmpfs inside the container (see podman run man page)

    An attacker would need to:

    1. Exploit the user inside the container to become root
    2. Exploit / break out of the container again to become just an ordinary user on the bare metal system (very difficult if you have limited the Linux Capabilities correctly)
    3. Exploit bare metal to become root & gain control of your system

    Run the container first without dropping any Linux capabilities & check podman inspect container_name to 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 use podlet to 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):

    Thanked by 3oloke twain user3028938
  • twaintwain Member
    edited January 22

    @itoffshore said:

    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.

    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?

  • @SlowDD said:
    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.

    That's not true. A hypervisor's attack surface is far smaller than a kernel's attack surface, especially with paravirtualization.

    Thanked by 1user3028938
  • forestforest Member
    edited January 22

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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?

    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.

    Thanked by 1whynotlearn
  • rpqurpqu Member

    @forest said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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?

    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

  • itoffshoreitoffshore Member
    edited January 22

    @twain said:

    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?

    I run all services as podman rootless containers which live under /home/unprivileged_user:

    # quadlet files
    /home/user/.config/containers/systemd
    
    # podman volumes with container settings (can be exported as tar files / imported)
    /home/user/.local/share/containers/storage/volume (overlays live under storage too)
    
    • files under /etc can also be edited - everything else is mostly immutable / & most of /usr except /usr/local:
    ~ # cat /etc/fstab
    
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 / btrfs ro 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /.snapshots btrfs defaults,subvol=@/.snapshots 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /home btrfs defaults,subvol=@/home 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /opt btrfs defaults,subvol=@/opt 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /root btrfs defaults,subvol=@/root,x-initrd.mount 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /srv btrfs defaults,subvol=@/srv 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /var btrfs defaults,subvol=@/var,x-initrd.mount 0 0
    UUID=91BC-8443 /boot/efi vfat defaults 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /boot/writable btrfs defaults,subvol=@/boot/writable 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /usr/local btrfs defaults,subvol=@/usr/local 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /boot/grub2/i386-pc btrfs defaults,subvol=@/boot/grub2/i386-pc 0 0
    UUID=908d4212-d506-4304-8d77-9a91e0043e54 /boot/grub2/x86_64-efi btrfs defaults,subvol=@/boot/grub2/x86_64-efi 0 0
    

    I create golden images with all packages / configurations included using:

    This creates a Micro OS iso that 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 ini file with ip's / gateways / macs - & rebuild the iso with the new ini file 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 /etc changes) - I run my iso build environment in a tumbleweed container with a zram build volume mounted - a new iso builds in 4-5 minutes on a Ryzen 5950x

    Thanked by 1twain
  • Another isolation option:

    "The speed of containers, the security of VMs"

  • @itoffshore said:
    Another 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.

    Thanked by 1itoffshore
  • @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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 are not getting it, passthrough is impossible with my hardware. :smirk: No software will magically make that possible.

  • @itoffshore said:
    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-50mb of RAM (see podman stats) - & it's simple to run containers as a system service with "quadlets"

    podman top container_name will 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:

    User=10000
    AutoUpdate=registry
    PodmanArgs=--cpus 0.5 --memory 128m
    PidsLimit=50
    DropCapability=ALL
    NoNewPrivileges=true
    

    In the example above the service is effectively running as user nobody on 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 tmpfs inside the container (see podman run man page)

    An attacker would need to:

    1. Exploit the user inside the container to become root
    2. Exploit / break out of the container again to become just an ordinary user on the bare metal system (very difficult if you have limited the Linux Capabilities correctly)
    3. Exploit bare metal to become root & gain control of your system

    Run the container first without dropping any Linux capabilities & check podman inspect container_name to 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 use podlet to 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):

    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.

  • user3028938user3028938 Member
    edited January 22

    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.

  • ralfralf Member
    edited January 22

    @DataWagon said:
    It’s sufficient isolation from the host as long as there isn’t some container breakout zero-day.

    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.

  • @user3028938 said:
    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.

    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:

    • a dedicated immutable os with secureboot / secrets in TPM / clustering + the ability to run OCI images (Docker / Podman) - very similar to Talos Linux (no SSH / management via API secured with mutual TLS) - needs secureboot at a minimum & can provide a software TPM if a physical one is not available.

    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.

    Thanked by 1user3028938
  • @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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 are not getting it, passthrough is impossible with my hardware. :smirk: No software will magically make that possible.

    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.

  • @forest said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:

    @user3028938 said:

    @whynotlearn said:
    LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible

    Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?

    I don't think that there is so much of a performance hit using kvm as you are assuming.

    It essentially depends on the type of workflow/how secure you want.

    There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)

    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 are not getting it, passthrough is impossible with my hardware. :smirk: No software will magically make that possible.

    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.

Sign In or Register to comment.