qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
* tazjin waves at qyliss
<qyliss> hello, you want to do some Rust?
* cole-h waves at tazjin
<tazjin> yes - but before I pick up any tasks, I'm actually gonna work through the manual
<qyliss> oh good idea :)
<tazjin> also there's a thing I want out of the cgit, but it's unimportant
<tazjin> I would like a button for "only show me spectrum related log messages" in the nixpkgs tree
<qyliss> that would be a very nice button
<qyliss> Would be good to have in crosvm too
<qyliss> Although there you can probably just search for Alyssa Ross
<qyliss> Which is not the case in Nixpkgs
<tazjin> yes, the heuristics for this aren't entirely clear
<tazjin> that's just an idea I had a few minutes ago, I'll let it stew until I come up with something
<tazjin> in the meantime,
* tazjin opens the manual
<qyliss> (that hash is the second parent of the most recent "merge nixpkgs" commit)
<qyliss> if I had an "upstream" ref we could have a stable URL for that
<qyliss> and then easily add a button
<tazjin> oh, neat
<qyliss> feeling pretty smart for that ngl
* tazjin pets qyliss
<cole-h> That tree of merges is kinda pretty
<qyliss> Would be prettier if merge commits weren't so heavily overused in nixpkgs
<qyliss> *This* is a pretty merge tree: https://spectrum-os.org/git/crosvm/log/
<qyliss> (it gets pretty on page 2)
* cole-h agrees
<cole-h> Which big green button does that? Rebase or squash?
<cole-h> (I'm assuming rebase)
<qyliss> Does what, exactly?
<qyliss> rebase produces a totally flat history
<cole-h> Makes history nice and clean
<cole-h> like that log
<qyliss> Yeah, that's the equivalent of Google and I both using rebase merges, but when I merge in their code I use a merge commit
<cole-h> OK, nice. When I merge stuff for borg, I will use the green "rebase and merge" button, then :D
<cole-h> (not that it makes much of a difference)
<qyliss> Merge commits, IME, only make sense for long-lived branches where the point of divergence matters
<qyliss> But that's a fairly controversial opinion
<cole-h> Do you have an example of that? Hard for me to visualize.
<qyliss> If I was in charge of Nixpkgs, I'd use merge commits for merging staging-next into master, and staging into staging-next, etc.
<qyliss> But not for some PR updating a package, for example
<qyliss> Does that make sense?
<cole-h> Yeah, I see now.
<cole-h> What about haskell-updates?
<qyliss> I'd merge that, probably.
<cole-h> I think I'd lean towards a merge for that, too
<qyliss> Because it's a long-lived branch that's periodically merged in
<cole-h> OK, cool. Thanks for solidifying some git stuff in my brain :D
<cole-h> (Well, we'll see if it's actualy solidified)
<qyliss> This follows pretty naturally from email git, fwiw.
<cole-h> True.
<qyliss> Like, if I receive a patch, I'll just apply it straight to master. It would be weird to make a branch, apply the patch, and then immediately merge --no-ff that branch.
<qyliss> But none of this is all that important, in the scheme of things :)
<cole-h> True, more just house-cleaning.
<qyliss> (And so naturally it's hugely controversial)
<cole-h> Heh
<qyliss> Okay, so in theory, I've hooked up the memfd server to crosvm
<qyliss> but I have so far tested none of it so it will almost certainly not work
<qyliss> (yet)
<qyliss> And indeed, it did not work :)
<tazjin> I don't actually think I believe in long-lived branches anymore
<qyliss> I don't think I do either in most cases
<qyliss> But, say, spectrum crosvm master is a long-lived branch to some extent
<qyliss> I guess you could distinguish that as something that will never be wholesale merged, though.
<qyliss> memfd server isn't working because i tried to allocate 8031938417022231912 bytes of memory
<tazjin> you might find that difficult to achieve without swapping
<qyliss> indeed
cole-h has quit [Quit: Goodbye]
<hyperfekt> > tazjin: I would like a button for "only show me spectrum related log messages" in the nixpkgs tree
<hyperfekt> oh god i wish this was a thing. seems strange to me still that there isn't a unique branch identifier in git. git could then add that to the commit's notes to know where it came from
<hyperfekt> qyliss> *This* is a pretty merge tree: https://spectrum-os.org/git/crosvm/log/
<hyperfekt> i really like this. so you rebase your new commits onto the latest commit before your commits, and then you do merge commits every time you add commits from upstream?
<hyperfekt> 8e55e9cole-h> What about haskell-updates?
<hyperfekt> if you merge that peti can't force push it anymore lol
<MichaelRaskin> If only Git kept the «branch of original commit»…
<Shell> branches aren't actually a thing in git, is the problem
<Shell> they're just... a reference to a commit which gets updated occasionally.
<MichaelRaskin> Branches are a thing, it's just Git that chooses not to sync information about them, and not to store it for too long
<qyliss> hyperfekt: well, I just commit directly to my master, and then merge commits for merging with upstream
<qyliss> but when I am ready to pull in, say, the stuff currently on the interguest branch, I'll rebase that
<qyliss> Okay, let's figure out why the VM thinks the virtio_wl send has failed when it hasn't.
<qyliss> I'm so excited
<qyliss> This is so close to working
<qyliss> I think it works!
<qyliss> VM connects to a virtio_wl socket called __crosvm_memfd, sends a message with a debug name and a size, memfd server on host allocates a memfd, and sends it back to the guest through virtio_wl
<Shell> very nice.
<Shell> qyliss: pls remember to limit how much memory stuff can allocate through this :p
<qyliss> yes :P
<qyliss> tbh probably should just run every crosvm in a cgroup, and do memory limiting that way
<Shell> mmm
<qyliss> but a specialised small limit for this would be reasonable too
<qyliss> anyway, we learned last night that it's already limited to at least <8031938417022231912 bytes :P
<Shell> XD
<qyliss> man I am looking forward to writing TWIS tomorrow
<qyliss> "Everything works now"
cole-h has joined #spectrum
<alj[m]> Congrats qyliss !
<alj[m]> ooooh looks interesting!
<qyliss> I've been thinking a lot about this sort of thing recently. Very relevant for us. Nice to find a paper on it.
<alj[m]> i also thought about microkernels while reading about spectrum. there is a firewall microkernel for qubes for example, that eliminates having to create and run a full sys-firewall VM and only requires 32 MiB. It was written in oCaml and based on "mirage" if i recall correctly
<qyliss> Yeah that sounds right
<qyliss> MirageOS is a popular microkernel written in OCaml
<pie_> what a coincidence c:
<Shell> MirageOS is a unikernel, not a microkernel.
<Shell> it is written in ocaml though.
<MichaelRaskin> Then there are NetBSD rumpkernel based things.
<qyliss> Sorry, yes
<Shell> MichaelRaskin: where you can't call fork(), iirc.
<qyliss> Unikernel
<alj[m]> ah terminology issues, I apologize
<qyliss> alj[m]: this paper is also about unikernels, though, so MirageOS is a relevant example :)
<Shell> also their API is not actually quite the NetBSD userland API, which makes the whole thing kinda hard to use.
<pie_> funny thing now that i thnk about it, one of the arguments back in the day against micro/whatever kernels was slower ipc as opposed to monolithic kernels or somesuch right? and yet here we are using heavyweight VMs
<pie_> (with a lot of hardware support i guess)
<qyliss> > we find that [carefully-configured Linux, with program running in kernelspace] outperforms microVM and at least one of the reference unikernels in all of the following dimensions
<alj[m]> just fyi my sys-firewall is doing nothing except forward the connections and is using 380MiB right now. it plain sucks. same for my vpn VMs and other one-service stuff. If there was a way to fix that, that would be amazing
<qyliss> I suspect we can do better :)
<Shell> pie_: also, microkernels have got a lot more micro and a lot faster. seL4 is nice stuff. Genode builds on it, esp in their Sculpt desktop operating system, and some of what they're doing is clever but not exactly *useable* in the way that Spectrum is likely to be.
<alj[m]> So far Spectrum promises to fix all issues/fullfill all dreams I had with Qubes, so that would be another amazing addition
<qyliss> The VMs I'm working with at the moment actually have a maximum memory size of 256M
<qyliss> We might have to raise that, but I haven't run into memory issues yet
<alj[m]> omg are you serious?
<alj[m]> thats amazing
<qyliss> Bear in mind they're not doing much
<qyliss> Running a Wayland compositor and a terminal
<alj[m]> better than the 400M minimum for qubes stuff
<MichaelRaskin> Shell: well, there is work on running lightweight Linux VMs inside Genode for both drivers and applications (I think some things work)
<qyliss> But 300M+ for a firewall does seem like a lot.
<qyliss> also important to remember you'll be running more VMs at once with Spectrum than Qubes
<alj[m]> when are you able to test more demanding stuff like firefox?
<alj[m]> one VM for every program/application, right?
<qyliss> That's the idea.
<Shell> MichaelRaskin: I am aware of this work.
<qyliss> I could in theory test firefox right now, but I suspect getting it running would be tricky.
<alj[m]> and VMs are grouped into security contexts, that define filesystem access and similar stuff?
<qyliss> alj[m]: that's sort of vague right now
* pie_ imagines spectrum + raptor
<qyliss> ideally in most cases VMs will request and be granted permissions case-by-case
<pie_> where are the massive government grants smh :)
<qyliss> e.g. you want to open a file in LibreOffice, so you grant a VM access to that one file through a trusted file picker
<alj[m]> Don't know how i think about that yet, I would have to try it with my workflows and such
<alj[m]> pie_: what is raptor?
<Shell> alj[m]: in theory, this system will integrate with existing toolkits via the same mechanisms as Flatpak's sandboxing (known as xdg-desktop-portal). GTK3, Qt, and large applications like Firefox have support for parts of it that just have to be enabled for applications to use a Spectrum-supplied filepicker whenever they would currently show a GTK/Qt one.
<alj[m]> gotcha
<alj[m]> i work almost exclusively from terminal but i guess that would be rather trivial to do too
<Shell> there's definitely going to be a significant degree of terminal support.
<Shell> otherwise qyliss couldn't work on... anything, tbh. :p
<alj[m]> terminals are great :3
<Shell> terminals are very good for some things and very poor for others. :)
<alj[m]> ofc :D but i generally prefer doing stuff with the keyboard instead of clicking on stuff and terminals are great at that ;)
<alj[m]> I also despise apps and websites that are not usable without mouse.
<Shell> they're usually not useable for people with screenreaders either, which is the sucky part.
<alj[m]> agreed
<MichaelRaskin> Is there any non-sucky part about (granted, non-image-manipulation) applications with poor or no real mouse support?
<MichaelRaskin> * non-mouse support
<FireFly> what about games? (depending on genre)
<MichaelRaskin> Some of them have control scheme that is effectively image manipulation…
<MichaelRaskin> Some of them do have keyboard-control mode!
<MichaelRaskin> Some need to ban aimbots which means that a sucky UI is a part of the challenge
<qyliss> Nice to know that per-application kernel configuration doesn't result in any real performance win (from the paper)
<MichaelRaskin> Nice to check but not surprising
<qyliss> Yeah
<qyliss> This paper is pretty much confirming my instincts
<qyliss> but still nice to have that confirmation
<MichaelRaskin> There is a ton of «yeah, but how to keep this off the hot path?» discussions for every feature
<cole-h> qyliss: Update: I am done with finals :D I'll see what I can work on later this week (gonna attempt to switch to NixOS sooner rather than later)
<qyliss> Nice! :D
<alj[m]> congrats cole!
<qyliss> congrats cole-h :) looking forward to working with you
<cole-h> <3 all
<qyliss> It's also nice to read that system call overhead isn't even that high for general use
<qyliss> Which means most of the benefit is just coming from kernel configuration
<qyliss> (And that's nice because kernel-mode linux isn't practical, but a good kernel config is)
<hyperfekt> alj[m]: we're running on kvm so weget kernel same-page merging, which i'm expecting to save quite a bit of memory
<qyliss> > Alharthi et al. study 1530 Linux kernel vulnerabilities and show that 89% of these can be nullified via configuration specialization
<alj[m]> hyperfekt: I'm all here for saving memory. I hate it when i cant open my f**king gpg vm or smth else small
<alj[m]> I just wanna send a darned email okay PC?! I already have 16Gigs RAM leave me alone
<hyperfekt> qyliss: this ties back in with my mention yesterday about teto wanting to specify needed kernel config for packages but eelco rejecting it with the comment that w ehave o way to verify that anyway
<alj[m]> > > Alharthi et al. study 1530 Linux kernel vulnerabilities and show that 89% of these can be nullified via configuration specialization
<alj[m]> that is crazy
<hyperfekt> alj[m]: i actually upraded to 32gb when i still had qubes and now i have nixos and live in ram luxury
<qyliss> That was a good paper
<alj[m]> I guess I'm waiting for Spectrum for a OS switch. I'd love to nix it up, but its just kinda impossible (read impractical) with qubes...
<alj[m]> qyliss: That means you have a very early beta (or even alpha) tester in me, if you want
<hyperfekt> actually i think most of the value of spectrum is going to be in the integration stuff. qubes is notoriously useless for day-to-day use because it's severely lacking in that part. crosvm is just what's going to enable that
<hyperfekt> useless as in most people have very big domains and everything gets compromised. i basically had like the driver ones, and then used a trusted one for keys, one for my applications and disposable ones for untrusted stuff
<qyliss> When I used Qubes I had very small domains, but then it was very difficult to use and then I gave up
<alj[m]> I'm trying to keep domains small too, but its hard
<qyliss> Yeah
<qyliss> I think that domain management is not a thing that comes natually to humans
<MichaelRaskin> Can confirm, having per-application containment with easy passing-in of necessary directories makes runnning everything scary inside per-instance containers quite acceptable
<qyliss> DispVMs in Qubes were very nice
<qyliss> Those were my favourite part of it
<alj[m]> also updating the templates is a nightmare. first i cobbled together a saltstack script to run updates, then they provided a gui for that, but in the end I'm still spinning up a management VM for every single template. and there isnt even a package caching mechanism built in, i had to do that myself
<qyliss> What eventually got me to stop using Qubes was that I broke a template, and decided to reinstall
<qyliss> And then never managed to get the installer to work again
<alj[m]> the anaconda(?) based installer is hell.
<alj[m]> and the second i heard about nix and NixOS I was like "damn I wanna configure VMs like this"
<alj[m]> Again: the second Spectrum is usable I'll at least set up dual boot if not switch completely
<MichaelRaskin> Wrong goal! A better goal is «as soon as isolation looks like it could in principle be working, I will try migrating my workflows into Spectrum-tooling VMs»
<alj[m]> um, yeah i guess?
<cole-h> Best goal: "as soon as I have free time, I will contribute to Spectrum"
<qyliss> using Spectrum-tooling VMs on Qubes or whatever is likely to be pretty difficult, I'd say
<qyliss> But I can't really substantiate that.
<MichaelRaskin> qyliss: well, for testing inside a domain with Nix installed it should be fine maybe?
<qyliss> difficult to say I think
<alj[m]> I'd love to contribute but I don't know what i can add (and if i know the necessary programming languages)
<cole-h> https://spectrum-os.org/todo.html Numbers 2 and 3 don't (appear to) need programming language knowledge :^)
<alj[m]> I'll look into those tomorrow
<qyliss> cole-h: I wondered if you might be interested in doing the chromiumOSPackages update when those release in a few days? There's an updateScript, so it's mostly fixing up patches and stuff.
<cole-h> I hope you don't feel like I've bullied you into it -- I was just letting you know there are more ways than contributing code!
<MichaelRaskin> Given that the overall design has not been discussed, and apparently also doesn't exist in qyliss' head, early testing might be pretty valuable…
<cole-h> qyliss: Sure, I could give it a shot. Would you mind giving a brief overview of what that would entail? (Especially how to use the `updateScript` attr would be useful)
<qyliss> cole-h: nix-shell maintainers/scripts/update.nix --argstr path chromiumOSPackages is the official way, that should work for any package in Nixpkgs with an updateScript
<qyliss> But this particular updateScript happens to be written so that you can also just run pkgs/os-specific/linux/chromium-os/update.py if that's easier to remember
<qyliss> Then do nix-build -A chromiumOSPackages -A spectrumPackages and check everything still builds, basically.
<qyliss> (It probably won't, there'll probably be patches I backported that no longer apply, etc.)
* cole-h wishes he paid closer attention to that update stream
<cole-h> lol
<qyliss> And then you can try to fix those up yourself, or we can work through them together
<qyliss> fwiw I just removed the packages in the update stream that were really problematic
<qyliss> since they weren't actually used any more
<cole-h> Like minigbm? I tried to run the script (and hadn't pulled recently) so it failed on that package :D
<cole-h> (Works now that I pulled... lol)
<qyliss> Oh, no, that was me forgetting to actually commit the default.nix file for that package
<cole-h> Hehe
<cole-h> When will this chromiumOS update appear, roughly?
<qyliss> This website has a good overview of Chromium OS release timelines: https://www.chromestatus.com/features/schedule
<qyliss> It's saying May 19, but it doesn't always happen exactly on time
<qyliss> And sometimes Chromium OS lags behind Chrome a little
<qyliss> You can see what's actually being served to devices here: https://cros-updates-serving.appspot.com/
<cole-h> OK, cool, thanks. If you haven't heard anything from me, feel free to ping. I'm west coast US, so there's a little bit of a time difference :P
<qyliss> So, basically, just try to run the update script every day from May 19. At some point it'll update, which you can see with git diff :).
<alj[m]> I'm confused, How are Chromium OS and Chrome browser related to each other?
<qyliss> alj[m]: they're not really, except organisationally
<qyliss> So they release at the same time, and have the same version numbers and stuff
<alj[m]> gotcha
<cole-h> "at the same time"-ish :P
<qyliss> Yeah
<qyliss> alj[m]: did you already read enough to understand what Chromium OS has to do with Spectrum?
<qyliss> I can explain if not, I'm not sure how much this is actually mentioned on the website
<cole-h> qyliss: Never knew about the update script. Pretty nifty.
<alj[m]> Spectrum is using crosvm the "VMM" from chromium OS and some kernel stuff
<cole-h> (update script being maintainers/scripts/update.nix)
<alj[m]> right?
<qyliss> Correct :)
<alj[m]> also the virtio WL thing
<alj[m]> ^_^
<qyliss> cole-h: it's quite neat, especially for updating multiple packages at once
<qyliss> I think it can do stuff like do everything you're a maintainer for
<cole-h> I wonder if I could leverage that for when I eventually get around to patching in all the binaries in fish's many scripts...
<alj[m]> i wish i new Rust well enough to help out :(
<cole-h> It's never too late to learn :) I'm sure some "easy" stuff will pop up eventually, as more work is done.
<alj[m]> I'll keep my eyes peeled.
<alj[m]> Btw any plans to upgrade to something like gitea?
<alj[m]> or move to another git instance like github?
<qyliss> I would consider that a downgrade :)
<alj[m]> I'll give it a read thanks!
<alj[m]> I completely understand all and agree with most of your arguments. Since I'm not used to using git like this, it still kinda feels like a step back in time...
<qyliss> Is there anything in particular you're missing, out of curiousity?
<alj[m]> not sure, but I'll get back to you when I can crystallize my thoughts
<qyliss> okay :)
<MichaelRaskin> alj[m]: also it _is_ step in time, with the intention of throwing away the results of unfortunate later events
<alj[m]> everything has its pros and cons IMO
<qyliss> of course :)
<qyliss> fwiw anybody is of course welcome to mirror the sources elsewhere
<qyliss> Sleep time I think
<qyliss> tomorrow I'll try to sandbox the memfd server
<qyliss> then integrate it into wlroots
<qyliss> (right now I'm just testing it from a little test C program)