qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<aaronjanse> Wow, crazy that the issue led to fixing a ZFS bug qyliss
edadqr has joined #spectrum
<aaronjanse> Would there be some way to build Nix derivations within a VM? I assume a user would typically just install all software beforehand, but it could be cool to be able to do `nix shell` inside a VM
cole-h has quit [Ping timeout: 240 seconds]
<qyliss> yeah, I think that would be good
<qyliss> the Nix part of Spectrum isn't very well thought through yet
<qyliss> that was in part because I wanted to fill this channel and the mailing list with as many Nix people as possible to provide input :P
<aaronjanse> Famous last works, but I don't think it would be too difficult to modify Nix to use crosvm as its build sandbox. I'm not sure if that would be useful at all
<qyliss> ideally I'd like Nix itself to run in a VM
<aaronjanse> Oh yep, that probably makes the most sense
<qyliss> have you looked at Nix's code? :P
<qyliss> but it could perhaps build in a different VM
<qyliss> one of my goals is to do as little on the host as possible
<qyliss> I don't even want it to know what networking is, ideally
<aaronjanse> I've looked at the Nix code. Its sandboxing code is fairly straightforward
<MichaelRaskin> Well, you will run the system built inside VM on the host anyway, but abusing that would require a targeted attack and then Sway is a cheaper target
<aaronjanse> I think it might make sense to have the build in a VM separate from Nix. That way, a chroot escape wouldn't mean compromising the integrity of the Nix daemon
<qyliss> yeah, although as MichaelRaskin says if you can produce malicious code that will be run as part of the built syste, it doesn't matter
<qyliss> but not every derivation produces code that will be run at runtime!
<MichaelRaskin> That's true…
<qyliss> so with a good sandbox, all your documentation and stuff is going to find it a lot harder to own your machine
<aaronjanse> I guess this all depends on whether dev VMs would build things inside the VM or send stuff to a daemon on the host machine
<qyliss> yeah
<aaronjanse> *"dev VMs" meaning VMs where the user is playing with Nix
<MichaelRaskin> Has anyone ever fuzzed the daemon connection
<qyliss> It's probably a good idea to keep the Nix that's responsible for building the whole system isolated, but I'm not sure
<aaronjanse> Not... yet!
<aaronjanse> MichaelRaskin: I might try that after exams next week. Last week I did a little fuzzing of Nix but didn't get far
<qyliss> my vision is increasingly of using Nix to build an immutable system image, that is small and rarely needs to change
<aaronjanse> qyliss: That makes sense
<qyliss> and in that model, it would make sense to use a totally different store and stuff from normal runtime Nix operations
<MichaelRaskin> > rarely needs to change > includes kernel, openssl, glibc, browser…
<MichaelRaskin> The host — maaaaybe
<qyliss> MichaelRaskin: I'm talking about the host
<MichaelRaskin> Soo, just KVM bugs to fix there?…
<qyliss> yeah
<qyliss> and VMM bugs
<qyliss> and then just bugs that would affect the bits of those systems we're using
<qyliss> dom0 in Qubes is usually very outdated, but it doesn't matter because it's not exposed to anything else, assuming there aren't any Xen escapes
<pie_> >w< cant wait for spectrum. maybe i can run discord without an immediate aneurism
<zgrep> qyliss: How often do they update Xen? :P
<zgrep> (I'd assume also infrequently, unless necessary.)
<qyliss> yeah
cole-h has joined #spectrum
ziq has joined #spectrum
<qyliss> I present the strace mailing list archive for this month: https://lists.strace.io/pipermail/strace-devel/2021-May/thread.html
<qyliss> I still didn't do the thing I started working on strace to do, whoops
<samueldr> whoops!
<MichaelRaskin> Will the yaks fear the rainbows soon?
<qyliss> wow, the VFIO documentation is really good https://www.kernel.org/doc/html/latest/driver-api/vfio.html
<qyliss> which is surprising for Linux documentation
<qyliss> (except for the typo on the first line, which I sent a patch for already)
<cole-h> nice
<qyliss> was really helpful in figuring out what all the arguments to this ioctl QEMU is failing on are
<MichaelRaskin> I think when I needed something from in-tree Linux documentation to understand some command-line stuff use, the docs were pretty good.
<MichaelRaskin> Is it usually not so for ioctls?
<qyliss> often they're not even documented ime
<MichaelRaskin> Ah
<qyliss> ioctls are a bit of a mess in Linux
<qyliss> they're basically syscalls, but they receive _way_ less scrutiny
<MichaelRaskin> There are also /sys entries, I guess.
<MichaelRaskin> (But there I think even breaking userspace i permissible)
<qyliss> and you end up with e.g. two different filesystems implementing the same feature with two different ioctl APIs
<qyliss> hmm, I don't think it is?
<qyliss> but yeah, I suppose ioctls are at least not sysfs
<MichaelRaskin> I think BtrFS at some point tried to have … interesting opinions on what fallocate does
<MichaelRaskin> No ioctl's involved!
<MichaelRaskin> (fallocate on BtrFS was rounded up to a size divisible by a block, which makes sense, and then set file length to that rounded-up value — way less sensible. When I asked people shouldn't BtrFS do, erm, something compatible with POSIX fallocate definition, first question was whether this even talks about syscalls and not only libc functions)
<MichaelRaskin> (it got fixed later)
<qyliss> wow lol
<MichaelRaskin> It did get fixed and I can understand why it wasn't a top priority (it was annoying with Nix…), but the question impressed me
<qyliss> idk that strikes me as annoyingly pedantic
<qyliss> how would libc even work around that?
<MichaelRaskin> Well, worse than pedantic, because in what universe glibc could be plausibly expected to check which FS it even is
<qyliss> well, if there was an fallocate_shrink_a_bit syscall, glibc could just call that after every fallocate, on every filesystem!
<MichaelRaskin> I mean, a libc could in principle stat and ftruncate if needed, but…
<MichaelRaskin> I think it was even in Drepper's days. We know what he would reply to such an idea, and this one time I cannot say the substance would be wrong.
<qyliss> MichaelRaskin: wouldn't ftruncate just round again, though?
<qyliss> if it always rounds up, you can't just fix it up afterwards -- you'd just be repeating the same thing at all
<MichaelRaskin> Well, at least on BtrFS at that time, no.
<qyliss> oh, so it would only round up if the size was increasing or something?
<MichaelRaskin> It was possible to create a file with length not divisible by a block, after all!
<MichaelRaskin> It was specifically about fallocate
<qyliss> oh sorry I mixed up fallocate/ftruncate
<MichaelRaskin> Which is a bit vague-ish
<MichaelRaskin> Well, with ftruncate it would make so little sense they would notice it before releasing anything