<qyliss>
fundamentally, there's no reason that anything other than crosvm should be running on the host system
<qyliss>
and as MichaelRaskin points out, it would be reasonable for people to run multiple compositors (although i don't expect it to be a standard setup)
maxdevjs has joined #spectrum
cole-h_ has joined #spectrum
<qyliss>
Managed to fix the spam filtering just before the spammers found discuss@
<qyliss>
They tried sending the same message there, and got blocked :)
<cole-h_>
:D
cole-h has quit [Quit: Goodbye]
cole-h_ is now known as cole-h
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
cole-h has quit [Client Quit]
cole-h has joined #spectrum
cole-h has quit [Quit: Goodbye]
<alj[m]>
nice TWIS, good read
<hyperfekt>
did the spam message use tazjin's address??
<hyperfekt>
i'm fully imagining spectrum bringing back trusted patgs a la ctrl-alt-del. i was always disappointed that microsoft got rid of that
<hyperfekt>
i think qubes must've gotten some corporate sponsoring because they implemented the UI domain separately from the admin one, maybe spectrum can access some of the same
<MichaelRaskin>
Wait what, Ctrl-Alt-Del is now possible to take over under Windows?
<loke>
Hello Specrum
<loke>
I mean Spectrum
<Profpatsch>
hello loke
<loke>
I'm a long-time qubes user, and was led here from Mastodon :-)
<loke>
Mainly because I'm not using Qubes on my home workstation for two reasons: 1) I need GPU access, and 2) need to be able to run virtual machines. I'm hoping that at some point in the future I'll be able to use something slightly more secure than Fedora. :-)
<loke>
I use Qubes on my work machines.
<loke>
Anyway, is there some alpha or earlier of Spectrum that can be tested? I'd love to see if there is anything I can help with.
<MichaelRaskin>
No; and ye
<MichaelRaskin>
There is nothing runnable as an entire system. But there are some things you could try to test, and there are some things you could try to help with.
<loke>
I have quite a bit of experience with both Linux, Unix in general and software development.
<MichaelRaskin>
What about Nix package manager?
<loke>
I tried Nix for a bit. I write a few packages for it when I tried to use it. I quickly lost interest when I realised that all the hoops it made you jump through didn't actually isolate the applications so what was the point.
<loke>
That's why I was curious hearing about Spectrum, since it seems to actually aim to do what I thought Nix was already doing.
<MichaelRaskin>
Well, slapping a namespace-based jail on top of Nix is cheaper and easier than over a normal package manager.
<MichaelRaskin>
(I do that)
<loke>
MichaelRaskin: Right. When I learned about the Nix design, I was asking myself "why on earth would go go though all of this hassle when you're not even doing isloation"?
<loke>
However, with isolation, I'm certainly willing to accept the extra hassle.
<MichaelRaskin>
Because Nix is older than cheap isolation
<MichaelRaskin>
And pointless package conflicts, as well as state accumulation, are also real problems
<loke>
MichaelRaskin: I know, I've been talking to Nix proponents about it, and I see and understand their aguments. They are not wrong, but it's just that I find other things more important. That's a very personal opinion of course.
<loke>
However, for me personally, having isolation as a feature completely changes the equation.
<MichaelRaskin>
Yeah, sure, nothing wrong with «not worth it for me»
<MichaelRaskin>
I think there is something in development inside Nix that will include cheap container-like isolation
<loke>
I'm willing to jump through a ridculous amount of hoops to get a reasonably secure environment. :-)
<MichaelRaskin>
Well, depends on your notion of «reasonably»
<loke>
MichaelRaskin: My definition is less rigid than that of Qubes.
<MichaelRaskin>
But containers do not cut it?
<loke>
For Qubes? No. For me, definitely.
<loke>
I'm OK with containers, as long as the isolation is done right.
<MichaelRaskin>
Do you firejail everything on your Fedora?
<loke>
MichaelRaskin: No. I run VM's, and as much as possible in flatpaks.
<loke>
Untrusted stuff goes in Virtualbox vm's. My development stuff is native
<loke>
It's ahassle, and I'm still not at all comfortable with my environment.
<loke>
Then I have two laptops.
<MichaelRaskin>
Ah OK, flatpaks sound comparable with other container-like options
<loke>
But right now it's all a mess. My laptops only have 16 GB RAM which is a bit too little for Qubes.
<loke>
And my Thinkpad has 24 GB RAM, but since I need to use it for Android development, I can't run Qubes on it.
<MichaelRaskin>
If you want _just_ VMs, even the well-established NixOS stuff actually has some nice things.
<MichaelRaskin>
Write a config, then nixos-rebuild build-vm it, done.
<loke>
I don't want VM's. :-) I want containers. That's the only way to get efficient GPU utilisation.
<loke>
My use of VM's is just a workaround.
<MichaelRaskin>
Well, Spectrum as is is likely to have only VMs
<loke>
Oh really? Similar to Qubes?
<MichaelRaskin>
More
<MichaelRaskin>
More fine-grained, using the power of Nix to avoid losing your mind while managing them
<loke>
And what about GPU support? I'd say that's one of the main blockers (if not _the_ blocker) in Qubes right now.
<MichaelRaskin>
There are some hopes for VFIO
<MichaelRaskin>
I would not say there is something clear.
<MichaelRaskin>
I would not say there is _anything_ clear about the overall design, to be completely honest…
<MichaelRaskin>
Well, and there is also GPU paravirtualisation
<alj[m]>
Wait, but crosvm is the mechanism Spectrum is using, correct? And crosvm uses minijail, no? I'm confused whats a VM, whats a container and whats a jail now...
<MichaelRaskin>
CrosVM puts some of the VM components into container-like Jails
<alj[m]>
now I'm even more confused :D
<MichaelRaskin>
These are managed by minijail
<MichaelRaskin>
CrosVM is a full VM using KVM
<alj[m]>
gotcha!
<MichaelRaskin>
It has the core VM manager (VMM), and also it emulates some devices or provides services to the guest OS
<MichaelRaskin>
Just like most of the code churn in Linux is device drivers, the most risky code — and the code easiest for the guest system to attack — is device emulation / service provision
<MichaelRaskin>
So the host part of device code runs (unless this is turned off…) in minijail-managed containers
<loke>
That's interesting. Thanks for the summary.
<MichaelRaskin>
loke: if you want containers for everything, I would probably look towards firejail or bubblewrap. I, personally, use nsjail with nsjail command lines generated by Common Lisp code.
<loke>
MichaelRaskin: Thanks. I don't know much about these tools.
<MichaelRaskin>
Well, or Flatpak where available
<loke>
I kind of like flatpak. That's how I package Climaxima.
<qyliss>
loke: my understanding is that GPU access in Qubes is limited beyond the limitations you get just from VMs
<qyliss>
flatpak is frankly a joke when it comes to security
<qyliss>
although if you're building your own flatpaks, maybe less so
<qyliss>
loke: I'd be interested to know what your GPU problems were with Qubes, and what you tried
<MichaelRaskin>
Flatpak is a joke because a pack can request more or less whatever access, or for some other reason?
<qyliss>
The application developer decides what priveleges to grant
<MichaelRaskin>
Ah, so the normal epic fail, not something nontrivial
<qyliss>
you also get whatever OpenSSL or whatever the application developer wants to give you
<qyliss>
so good luck with that staying up to date
<adisbladis>
I also think the flatpak "runtimes" are a fundamentally bad concept
<qyliss>
There is some neat stuff coming out of flatpak, though
<qyliss>
xdg-desktop-portal is very exciting
<adisbladis>
Absolutely :)
<adisbladis>
Just not flatpak itself ;)
<qyliss>
yeah
<adisbladis>
I find the runtimes to be in a very weird spot
<adisbladis>
In some way they promote a lot of sharing, except when you start pulling in stuff that's not in one of the base runtimes
<adisbladis>
Then there is absolutely no sharing
<Profpatsch>
Isn’t the base idea for flatpak to avoid having to go through the distribution?
<qyliss>
yes
<Profpatsch>
Aka businesses shipping whatever nonfree binary crp they come up with
<qyliss>
very convenient for application developers, not so good for users
<Profpatsch>
aka making it like windows
<Profpatsch>
I like how the wikipedia article doesn’t mention which companies push for it
<qyliss>
Flatpak is RedHat
<Profpatsch>
Developers “Flatpak Team”
<Profpatsch>
lol
<qyliss>
Snap is Canonical
<qyliss>
And AppImage is the sort of independent one, so naturally it has the best implementation and nobody uses it
<qyliss>
but the concept behind all of these is bad anyway
<Profpatsch>
It’s undermining the free software movemente
<Profpatsch>
-e
<ehmry>
its anti-computer-science
cole-h has joined #spectrum
cole-h has quit [Client Quit]
cole-h has joined #spectrum
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
<loke>
qyliss: Appimage is kinda neat, but it has no isolation.
<loke>
qyliss: And for GPU in Qubes, it's simply not supported.
<qyliss>
well, that's not a fundamental limitation of VMs
<qyliss>
It's a bit early to say for sure, but I'd expect Spectum to at least be able to attach the GPU to a single application at a time
<qyliss>
Using multiple applications on the GPU at once might be possible, but I'm not sure
<MichaelRaskin>
Qemu has virgil3d
<qyliss>
crosvm has virtio-gpu
<qyliss>
and also virtio_wl has dmabuf support
<loke>
qyliss: It's a fundamental limitation of Qubes. Thea rgument being that it's impossible to get proper isolation with the GPU. And VGPU is only supported by the enterprise versins of the grpahics cards (for business reasons)
<MichaelRaskin>
I think virgil3d is the host part for virtio-gpu to provide acceleration in a paravirtualised way
<qyliss>
oh, hmm
<loke>
Here's the statement from Qubes:
<loke>
"Those won’t fly. We do not provide OpenGL virtualization for Qubes. This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure."
<qyliss>
Our GUI virtualization infrastructure (which is really mostly Chromium OS's GUI virtualization infrastructure) is unlikely to have that problem.
<qyliss>
It to some extent already has GPU support
<qyliss>
(Although I'm not entirely sure to what extent that is)
<qyliss>
Gonna do some server updates; expect instability for a short time
<loke>
qyliss: Interesting.
<qyliss>
It's too early to say anything for sure with regards to Spectrum, but there's no fundamental reason you can't use your GPU in VM
<loke>
qyliss: The argument from Qubes' side is that it's impossible to ensure that one VM can't access another through the GPU. The complexity of GPU drivers is one argument I've heard.
<qyliss>
That's even more true of containers though
<qyliss>
If you're fine with containers, I don't see why you wouldn't be fine with two VMs sharing a GPU
<loke>
Apparently none of the GPU cards support a full reset at runtime, which is required if you want to be able to assign the card to a VM and then move it to a different VM
<qyliss>
Hmm, that does sound like more of a problem
<loke>
qyliss: Yes, I'm fine with containers. The Qubes team is not, however.
<qyliss>
I understand that
<qyliss>
I understand why Qubes does not want to support this
<qyliss>
But you were saying you wanted containers not VMs, because VMs couldn't do this
<qyliss>
And I was trying to understand why that was
<MichaelRaskin>
I think Intel (of all GPUs) supports GPU virtualisation, but f course for _Qubes_ threat model they just look at Meltdown and shudder
<loke>
MichaelRaskin: Oh yeah, Intel does support that. I forgot about them :-)
<loke>
My home workstation has a 5700 XT though, and it would be kinda sad to make it into a doorstop.
<qyliss>
I don't think the default should be to share GPUs between VMs, but for lots of people it's either let them do that or they can't use a compartmentalized system at all
<qyliss>
So giving them the option to do that (with some big red warnings about why it's a threat) is something I'd be very happy to do, if it's possible
<qyliss>
I'm wondering about the role of dmabufs here
<qyliss>
I don't entirely understand what they do yet
qyliss has quit [Quit: bye]
<hyperfekt>
my understanding is that our best bet for fast graphics is KVMGT. AMD's and Nvidia's GPU virtualization solutions are for their professional cards only.
qyliss has joined #spectrum
<loke>
hyperfekt: yes, and it's very sad that that is the case. It's purely a software lock.
<hyperfekt>
loke: i've seen lots of mentions of changing resistors on nvidia cards to get them to do resets, maybe it's possible for that too
<hyperfekt>
but maybe with intel xe we won't have to and can just support a manufacturer that doesn't limit security to those willing to pay multiples
<qyliss>
nvidia is unlikely to work well until they sort themselves out with wayland, fwiw.
<qyliss>
08:53 <hyperfekt> did the spam message use tazjin's address??
<qyliss>
no??
<hyperfekt>
qyliss: oh that's strange, because protonmail said his mail failed one of SPF/DKIM/DMARC
<qyliss>
oh interesting
<qyliss>
i'll look into that
<tazjin>
that's odd, the mail went out via Gmail, I'd expect that to work correctly (tm)
<qyliss>
Yeah, it'll be something on the hop from me to hyperfekt
<qyliss>
SPF passed
<qyliss>
DKIM failed though
<qyliss>
So probably the list modified a header it shouldn't have
<hyperfekt>
nlnet should be glad, they get not only spectrum-os out of this but also a nice mailing list setup
<qyliss>
mailman in nixpkgs is in a much better state than it was before spectrum :)
<qyliss>
tazjin: could you forward me the copy of the message you received via CC?
<qyliss>
(MIME forward, to keep the headers intact, please)
<hyperfekt>
qyliss: where does one get actually good spam filters? i presume all the really good ones aren't public
<qyliss>
hyperfekt: I'm using spamassassin
<qyliss>
the thing about spam is that the vast majority of it is really obvious
<qyliss>
e.g. the spam message that got through scores 16 with my spamassassin rules (which come from public-inbox), and I'm now holding any message that scores >3
<qyliss>
Most legit emails score negative
<qyliss>
there is doubtless good spam out there that'll get through, but it's really a numbers game
<hyperfekt>
i see. i thought spammers were better lol
<MichaelRaskin>
hyperfekt: for most of them, only hitting the most naive people or only hitting the people whose work email is similar to their spam is a _plus_
<MichaelRaskin>
Hitting Spectrum-OS mailing list and evading the filter has more or less no positive outcomes for them, but someone could try hooking an Elisa on that…
<qyliss>
MichaelRaskin: they're also trying to generate backscatter, fwiw
<MichaelRaskin>
Well, in a way backscatter requires emails being rejected at least once!
<tazjin>
qyliss: I'm not sure I can, I think it got deduped
<qyliss>
hmm, that's a shame
<qyliss>
tazjin: CC me directly on your next patch?
<tazjin>
will do
<qyliss>
cheers
<tazjin>
I'm currently spending my free time on my nix fork, need to see when I can get in a patch
<hyperfekt>
tazjin: do you use chore() for the unfun things and feat() for the difficult ones?
<tazjin>
hyperfekt: I think most of them are ending up as refactor()
<tazjin>
I'm getting to the point in an hour or so where I can run a bunch of clang-tidy fixes over the whole codebase
<tazjin>
it's going to be very satisfying
xantoz has quit [Quit: WeeChat 2.8]
xantoz has joined #spectrum
<hyperfekt>
i'd be worried about you sorting inventorying the gold pile
<hyperfekt>
will i ever learn to check a message after editing it but before hitting send
<Profpatsch>
tazjin: if you clang-tidy it, it might be very hard to submit things upstream after.
<Profpatsch>
at least if it does reformatting
<tazjin>
Profpatsch: I have 0 intention of submitting things upstream
<tazjin>
my diff is already at ~10k lines
<Profpatsch>
-10k :)
<tazjin>
not entirely :p
<Profpatsch>
tazjin: not yet in depot?
<tazjin>
there's a branch, but I haven't pushed the last few things yet