<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>
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