Can I get a second opinion on my fun/slighly-mad idea? (Direct p2p networking, streaming, two ethernet controllers)

First a little background, feel free to skip this and jump to the questions:

I’ve been playing around with Qubes OS and, like so many before me, am contemplating putting together a new computer and making Qubes my “daily driver”.

The twist is that I’m considering using a motherboard with two in-built Ethernet ports and having the second port permanently occupied by a cable tether to a (otherwise offline) Debian mini-pc.

I’d interact with this mini-pc via a dedicated streaming quebe using some manic combination of steam link, sync-thing and Tiger VNC. (I’ve got steam link/remote working over a direct Ethernet connection in the past.) I’d attempt to use a combination of apt-mirror and file transfers to update the mini-pc when I’m inevitably forced to by some software requirement.

My motivation here is that I’m a 3D software developer and need some basic GPU acceleration for testing builds with 3D graphics and creating some low poly blender models. While convoluted I figure the setup above is the best way to accomplish that without GPU pass-through. TBH I don’t have a serious requirement for security, I just like coding with rust and am very paranoid about an inevitable supply chain attack.

Now I suspect to accomplish this hypothetical setup I’m going to have to pass my second Ethernet controller (the one connected to the mini-pc, not the internet,) directly to the streaming VM. This is where my questions come in…

Here’s the actual questions:

  1. In general if I pass-through an ethernet controller directly to a Qube VM, does it pose a security threat to anything OTHER then the VM its getting passed to? (Like how passing through a GPU to a qube potentially compromises the whole system, rather then just the qube its passed to.)
  2. My motherboard would have two built-in ethernet ports, so presumably it would have two ethernet controllers. Does anyone predict issues with Qubes recognising these two individually and passing through one direct whilst separately communicating internet via the other controller using the normal firewall qube?
  3. If you read my whole post, what do you think? Is this nonsense worth a shot? (If you didn’t, no worries, just ignore this :wink:.)

I appreciate its pretty unlikely anyone has had first hand experience with exactly this scenario, I just thought I’d throw this out there and see what people think. I’m probably going to end up gambling money on testing this, so it would be irresponsible not to check I haven’t overlooked some obvious problem first :slight_smile: .

First I have to say that I see some contradictions in your post.

For example you say “I don’t have a serious requirement for security” (why do you use Qube at all then?) only a second later to say “and am very paranoid about an inevitable supply chain attack”, and yet your first question is related to security, serously caps locked.
Then, you say “offline Debian mini-pc” which is “cable tether”-ed.

Nevertheless, nothing is secure 100%. Even offline qubes are not immune to side channel attacks. And many other kinds of them. That is why Qubes is advertised as “reasonably secure” OS. No other OS can help you more. So, passing devices to single qubes is much less dangerous than to have them in dom0.

At the end, your idea is interesting to me and I find it legit. I’m sure someone else will have additional and different views.

Perhaps this is relevant:

I accidentally double posted, removing this post’s text for brevity

Thanks for the reply enmus!

First I have to say that I see some contradictions in your post.

For example you say “I don’t have a serious requirement for security” (why do you use Qube at all then?) only a second later to say “and am very paranoid about an inevitable supply chain attack”, and yet your first question is related to security, serously caps locked.

Fair, my apologies, I did contradict myself alot. I was trying to convey that whilst I feel a pressing need for security from a supply line attack, I’m aware most of my peers wouldn’t feel the same need. Full disclosure, I worry too much (to the point of being medicated for it) so I tend to assume I’m being overly secure vs the actual level of threats I face. So basically I was saying I -want- security, but I probably don’t -need- it. Admittedly this might be the wrong place to say that, as this is perhaps one of a few places where people would agree my levels of precaution are reasonable.

Then, you say “offline Debian mini-pc” which is “cable tether”-ed

Whoops, terminology failure, my bad. By offline I meant “not directly connected to the internet”, after a short trip to an online dictionary I now realize that’s not exactly what offline means.

At the end, your idea is interesting to me and I find it legit. I’m sure someone else will have additional and different views.

Glad to hear it! Maybe I’ll post back here and let you know how it went if I go ahead.

Perhaps this is relevant:

Definitely relevant, thank you fsflover! Looking through that it seems like the controller was a threat to every VM in the “connected chain” of VMs it was serving. So even if the issues in that bulletin hadn’t been fixed, my hypothetical the controller connected to a mini-pc would only have threatened my streaming VM, which is perfectly acceptable to me.

I was more worried that Ethernet controllers were going to turn out to be like PCI graphics cards in that they could (in theory) be used to influence dom0 from within a virtual machine they’ve been passed to. Which I guess is a silly concern anyway, given nearly everyone here has a controller passed through to their sys-net VM.

Please apologize in advance again, but maybe I don’t understand since English is not my first language. Controller is attached to a streaming VM, not to a mini-PC? Mini-pc is connected to streaming VM via cable, right? When so, mini-PC would be threatened by your streaming VM, not vice versa?

When not, then ports would share the same controller, and it’s no good for anything attached to common controller. So, you’d have to be sure about that before trying?

If I were you, instead of this I’d rather conclude with something like:
“… it wouldn’t increase the threat level of (the rest of) my system…”,

simply because ethernet controller isn’t the only threat to a (from) streamingVM

No worries. I’ll assume that’s why you just asked me to apologize in advance :wink:. Either that or I’m about to do something very offensive… I sure hope not :laughing:.

In all seriousness though thank you for helping.

Well spotted, I expect you’re right. But to be honest that’s not something I’m concerned about. My objective is to have both the mini-pc and the streaming VM be the same level of trust. The main thing I want to avoid is exposing dom0 or other unrelated VM’s to extra risk.

Are you implying here that my streaming VM would pose a non-trivial risk to the rest of my system. (Not just the mini-PC). If yes could I get you to expand on this?

Good point! I had intended to build the computer around a MSI MAG Z490 TOMAHAWK (MSI MAG Z490 TOMAHAWK ATX Gaming Motherboard (10th Gen Intel Core, LGA 1200 Socket, DDR4, CF, Dual M.2 Slots, USB 3.2 Gen 2, Type-C, 2.5G LAN, DP/HDMI, Mystic Light RGB) 輸入訊息). But if both its Ethernet ports share the same controller then that’s pointless. Is there any way I can figure out how many Ethernet controllers the board has? (Without buying it or knowing a guy at MSI.)

You should read and follow

if you’re enough about security to give you an idea. For example, check the last that Qubes is affected by

(ain’t @fsflover and I too pushy persistently posting links to (official) docs, hahah?)

It’s the question for MSI and the best way to do that is to either write to them directly and in advance or to check their forums.

Of course, and if you didn’t miss side channel attacks I mentioned above.

But this should not stop you from your idea, because I still believe is interesting and legit, while not necessarily increasing threat level of your system.

On the contrary, it very much reminds on the next step in Qubes evolution (whatever my concerns would be about it)

That issue is fixed, isn’t specific to streaming and wouldn’t have effected me because of the Z490’s intel processor. So I assume you’re just trying to remind me that Qubes OS’s security (like all security) isn’t 100% effective? :slight_smile:

Which is fair enough. But I’m not looking for perfection. I just don’t want Qubes’s default security to be made significantly worse by my weird idea. And since we both seem to think it wouldn’t cause any obvious extra threats I’m happy.

I’ll bookmark the tracker too if that’s what you were hinting at :grin:.

Great advice! Look what I found: MSI MAG Z490 Tomahawk - WOL configuration problem | MSI Global English Forum - Index

Looks like the Z490 is a winner!

Fascinating stuff. I’ll go ahead and try my idea out and post back here with my results when I have some. (Assuming this thread doesn’t get locked with age.)

Thanks again for all your help.