qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
Thierry64 has quit [Read error: Connection reset by peer]
Thierry64 has joined #spectrum
pie_ has joined #spectrum
spacekookie_ has joined #spectrum
spacekookie has quit [Ping timeout: 244 seconds]
spacekookie_ is now known as spacekookie
<pie_> people be like "muahahaha i have root" - wish i could be like, "lol who is root even"
<pie_> internet CVE blues
<qyliss> hehe
<qyliss> I really need to set up a mailing list
<qyliss> tomorrow will be the day
jpo has joined #spectrum
<jpo> adisbladis: qyliss: I think using blockchains as proof-of-publishing of source releases & build artifacts makes a lot of sense
<jpo> at one point qubes was using https://opentimestamps.org/ for that (built by peter todd, a fellow qubes (+ bitcoin) person)
<jpo> or maybe using some predecessor, i forget
<jpo> someone was also using it to publish source repo hashes on the blockchain so that if signing keys were ever compromised, then, if the time at which the signing key were compromised was known, one could reasonably scope an audit to the last known-good timestamped commit
<jpo> hyperfekt: re hooking exec => separate VMs - this is not really feasible because of resource overhead. have you looked at Genode? they have a much more reasonable approach to what it sounds like you probably want to achieve
<jpo> tazjin: re "would a session with some Chrome[ium]OS / crosvm people be useful" - i don't speak for qyliss, but i personally am quite interested in what they've done and wouldn't mind exchanging ideas and learning from their (not well documented outside google) experience. do you have some connection to that team?
<tazjin> jpo: via one (human) edge, I can reach out and ask on Monday - also, welcome! 🙂
<jpo> qyliss: re wayland-virtfs: "I'm guessing that they currently, for example, share the clipboard. That would be Extremely Not Okay in Spectrum," - well automatically propatating contents between trust boundaries perhaps isn't, but leveraging already-guest-supported clipboard transport mechanisms is certainly useful. the less guest-agent stuff is necessary the better
<jpo> tazjin: i don't have any specific questions for them at the moment, but if i ever happen to be at the same event as some of them i'd absolutely love to discover my unknown unknowns about their efforts
<tazjin> jpo: will you be at Congress? (I think I asked before but forgot your answer)
<jpo> tazjin: i don't currently have tickets or plans, but i've been meaning to go for years
<jpo> qyliss: re: "A magic \"run this in a completely unrtusted sandbox\" command like qrexec would be a good thing to have" - yeah. i don't believe qrexec is a good sole model to take inspiration from though
<hyperfekt> jpo: Genode is super cool but if I want Linux compat without porting it probably comes down to every application running in a Linux VM. The TCB is much smaller, but using advanced features becomes harder in turn compared to KVM.
<jpo> ah, sure. i wouldn't do it via hooking exec though, but rahter make it an explicit wrapper to compartmentalize at the granularity that *you* want, because otherwise things like `make` become excruciatingly slow
<jpo> re qrexec: its CGI-script-like semantics do make it easy to implement simple RPC things in shell scripts, but its lack of type-safe argument marshaling has resulted in some less-than-ideal ad-hoc parsers, and we at a minimum should have had an unambiguous way to separately encode arguments for exec (rather than a string that's blindly escaped on one side and un-escaped with potentially-different semantics on the other side)
<jpo> qyliss: samueldr: thanks for the backlog :)
<hyperfekt> jpo: Are you familiar with LightVM? Changes to Xen that boot a unikernel in 4ms. Sure your system is slower, but I would argue not necessarily excruciatingly so.
<jpo> you mean the research project from NEC?
<hyperfekt> jpo: afaik it's under wings of oregon state now, but yeah
<jpo> sure, but a specialized minimal self-contained unikernel is not exactly the same use case as something which requires the ability to execute other code with linux system interface compatability and live interopration with the invoking environment (at the very least passing I/O for stdio, but also all the random stat/open/etc. used by {shared library loading, /usr/share/whatever slurping, etc.}
<jpo> don't get me wrong, i'd love finer-grained isolation for legacy workloads, i'm just not convinced that particular approach is feasible
<jpo> also tazjin, hyperfekt, sorry. if we've met, i've since forgotten who was who. my appologies if i make incorrect assumptions
<hyperfekt> That's true, it's more of a 'lower bound'. Lots of optimizations could be done to get close, for example pre- or lazyloading the image. While not easy, it doesn't seem fundamentally infeasible.
<hyperfekt> jpo: We haven't met yet :)
<jpo> hyperfekt: i agree with you. AFAIK it remains to be seen in practice, however
<hyperfekt> Yeah, only implementation will tell for sure. :b I really appreciate your input btw. :)
<Shell> btw: there's no actual need to use a proof-of-work blockchain, just distribute blocks referencing the previous blocks to enough people or publish them in a newspaper or something, since you're the only trusted source of info.