[00:00] <JackFrost> A wild Faux!
[00:00] <JackFrost> Hello.
[00:01] <Faux> Hello.
[00:01] <JackFrost> (I'm Unit193.)
[00:01] <Faux> I guessed, from the whois.
[00:08] <tsimonq2> JackFrost: I thought you were a GCI student, to be honest. Heh.
[00:25] <stgraber> jjohansen: hmm, if the check isn't ns_capable() then it would always fail inside an unprivileged container
[00:26] <stgraber> jjohansen: and would always succeed inside a privileged container (as we don't drop whatever caps it's looking for)
[00:26] <stgraber> jjohansen: unless it's an unpriv container which is spawned through a binary that's got an fscap added, then indeed the sysctl would block that :)
[00:38] <jjohansen> right, but seccomp uses its own mechanism, and so do some of the other users
[00:38] <jjohansen> of ebpf
[00:39] <JackFrost> A code browser would be useful enough as it is, such that one doesn't have to download the package just to check something quickly.
[00:39] <jjohansen> which actually is concerning in that, we need to check these as well and the sysctl mitigation may not be sufficient
[00:40] <stgraber> yeah, at least seccomp should be fine as it's not full on ebpf, it's a much more restricted subset of bpf
[00:40] <stgraber> I have no idea what iptables and others do
[00:41] <stgraber> but since they don't have a long lasting process to attach the program to, they clearly have some other mechanism to deal with this
[00:41] <stgraber> so long as we don't break seccomp with this (and lool's testing suggests we aren't), we should be fine
[00:41] <stgraber> and since it's a sysctl, someone can always flip it back if it's critical for their operation
[00:41] <stgraber> though not sure how that'd play with livepatch :)
[00:44] <wxl> ypwong: just got a new HP Envy and it appears to have an Insyde BIOS, so potentially liable to the whole intel_spi bug. Is there any way I can help with testing that won't necessarily brick my device (forever)? :)
[00:45] <jjohansen> right, the sysctl looks like it isn't going to break too much, so it works as a mitigation until we can get the larger change out
[00:46] <jjohansen> we just wanted you to be aware we were flipping it as LXD was one of the places where we figured problems might surface
[00:52] <stgraber> yep, thanks for the heads up
[01:32] <ypwong> wxl, i am afraid not... yet
[01:32] <wxl> ypwong: ok, well i dedicate my machine to the cause, should you need a tester :)
[01:33] <ypwong> wxl, that's great! Thanks for the offer. Will loop you in when we have something reliable to be tested :)
[01:34] <wxl> sounds good :)
[01:36] <tsimonq2> ypwong: I know it may be a lot to ask right now given the holidays (Happy Holidays, btw!) but is there a timeline at all? (If not, what's the current status of getting that fixed?)
[01:43] <ypwong> tsimonq2, although it's holiday but Mika from Intel and I have been trying out to recover the bios from ubuntu, we have something that works sometimes but since it doesn't work always we are afraid there will be risks in breaking other things.
[01:45] <tsimonq2> ypwong: Alright
[01:45] <tsimonq2> ypwong: Keep us updated, and many thanks to everyone that's been involved in dealing with this!
[01:45] <wxl> +1
[01:46] <tsimonq2> s/dealing with this/getting this solved/
[04:42] <wxl> ypwong: is there a definitive way i can determine whether or not this particular insyde bios is affected? from what i read in the bug report, it wasn't entirely clear that it was a problem with the BIOS manufacturer or the chip manufacturer.
[04:42] <ypwong> wxl, yeah, we are also not sure yet, i just starting talking to insyde to find out more
[04:43] <wxl> ypwong: ok. i'll leave you alone some more XD
[04:49] <ypwong> :)
[20:18] <Fra> ciao
[20:18] <Fra> !list