VirtualBox On Linux Affected By Security Vulnerability Leaking Host Data To Guests

[polarathene]

Spice isn't hw accelerated via the host, it is via guest.

Yeah I'm aware there isn't much point when using spice client on the same system, but the other user seemed interested in remote clients where it may be appropriate.

Perhaps I misunderstood but look at the docs: https://www.spice-space.org/spice-us...videostreaming

SPICE streaming allows sending an encoded video stream of the guest desktop to the client. The encoding can be done from the host (inside SPICE server) or from the guest, with the help of the SPICE streaming agent.

The streaming agent is a daemon/service running in the guest OS so it must be installed if it does not yet exist on the guest system. It relies on a dedicated spiceport char device to achieve communication between the guest and the host.

For host video encoding, SPICE natively supports MJPEG encoding. For using further codecs, SPICE server must be compiled with GStreamer support.

That sure sounds like it supports encoding on the host? The docs show libvirt and QEMU command config to support such as well. Then pairing virgl for 3D accel in a linux guest at least, you'd get an alright experience supposedly (or I think Spice can be paired with GPU passthrough too if that's desired).

[Quackdoc]

That sure sounds like it supports encoding on the host? The docs show libvirt and QEMU command config to support such as well. Then pairing virgl for 3D accel in a linux guest at least, you'd get an alright experience supposedly (or I think Spice can be paired with GPU passthrough too if that's desired).

it supports encoding, but only software currently supports vp9 and x264 software encoders last I checked.

[polarathene]

it supports encoding, but only software currently supports vp9 and x264 software encoders last I checked.

Are you referring to guest encoding or host encoding? While I have not tried setting it up the mention of gstreamer for codec support gave the impression if using host encoding it would be whatever is supported on the host? So if gstreamer on host is able to provide GPU encoding that should be an option too.

Looked the up source and seems you're right

I did see a patch from 2018 that seemed to have x265 support, but no GPU encoders for some reason. At a glance, it doesn't look like there is much there specific to x264 support, so perhaps adding other codecs that gstreamer supports is minimal addition to patch support for. I know that the official docs themselves have fallen a bit out of date.

[Quackdoc]

Are you referring to guest encoding or host encoding? While I have not tried setting it up the mention of gstreamer for codec support gave the impression if using host encoding it would be whatever is supported on the host? So if gstreamer on host is able to provide GPU encoding that should be an option too.

Looked the up source and seems you're right

I did see a patch from 2018 that seemed to have x265 support, but no GPU encoders for some reason. At a glance, it doesn't look like there is much there specific to x264 support, so perhaps adding other codecs that gstreamer supports is minimal addition to patch support for. I know that the official docs themselves have fallen a bit out of date.

like I said, I tried to add it before but was running into a driver crash. so I wound up giving up out of annoyance

[linuxgeex]

I have heard of DistroBox (uses Podman) for containers that are more integrated with the host system and support running graphical apps as if they were native on the host. Haven't looked into those if they provide the other features I'm interested in such as suspend/snapshots.

I haven't heard of those so thanks I will look into it.

I don't know much about LXC personally. The binding part is taking exclusive access of the GPU? That's not what I'd want if that's the case.

LXC is basically the same as OpenVZ if you know that. Docker is also based on it. There's support for snapshots and live migration, it runs the environment in a chroot with a combination of SELinux, namespaces, bind mounts so that you're running the guest's binaries on your host's kernel, but you can have root and/or user access to host hardware if you like. So it can be exclusive (root) or cooperative (user) access to the hardware.

Thanks for taking the time to share your knowledge and experience though

Thanks right back at you, it's always a pleasure to share with enthusiasts in something that interests me!

PS I recommended XFCE/Compton because it's an exceptionally low resource way to have a composited desktop with modern features, which is especially handy if you are running multiple graphical guests on the same host node. KDE5/Plasma is pretty but I had less luck balancing latency, stability, and aesthetics on low-bandwidth links. So I tried Fluxbox+Compton, which has similar window management features to KWin, but its app menu was too much work to maintain. So then Xfce4 for Whisker. xfwm4 lacks some of KWin's creature comforts, xfrun4 lacks some of KRunner's. TBH I would be happiest with KWin + xfce4-panel + thunar as a desktop environment if KWin could be separated from KDE like it could back in KDE3 days.

[polarathene]

LXC is basically the same as OpenVZ if you know that.

I've heard of them, haven't found the time to look into them further since Docker had been sufficient/convenient thus far. Might be worth looking into for this though, thanks!

if KWin could be separated from KDE like it could back in KDE3 days.

KWinFT might be suitable. It's KWin compatible for Plasma, but can also be used as another wlroots (which supports X11 I think) compositor AFAIK.

And yeah that's a good case for XFCE/Compton. I don't have much remote sessions for these, but if I do and it's an issue I'll consider taking that helpful advice

[linuxgeex]

I've heard of them, haven't found the time to look into them further since Docker had been sufficient/convenient thus far. Might be worth looking into for this though, thanks!

Docker is based on LXC tech. Canonical basically took LXC and made a REST API for it, and called it LXD. Then they focused on boot performance to get the initialisation component to be very small so it was ideal for microservices, and they rebranded as Docker. Then they built up the image repo and community, and Kubetnetes appeared separately, which is the main driver of Docker's popularity today... but under the hood it's still LXC.