12:03:13 <jki> #startmeeting CIP IRC weekly meeting
12:03:13 <collab-meetbot> Meeting started Thu Oct  6 12:03:13 2022 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03:13 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03:13 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:03:20 <jki> #topic AI review
12:03:24 <jki> 1. Resolve/ignore failures of KernelCI on 4.4-cip - alicefm
12:04:01 <jki> likely no news without alicefm around
12:04:27 <jki> 2. Add qemu-riscv to cip-kernel-config - patersonc
12:04:46 <patersonc[m]> Ah sorry, not done yet
12:05:08 <patersonc[m]> Although I don't remember that action ;)
12:05:22 <jki> read the logs ;)
12:05:28 <patersonc[m]> Ah yes, I've read up now :P
12:05:30 <patersonc[m]> Sorry
12:05:33 <jki> np
12:05:34 <alicefm> Hi
12:05:39 <jki> Hi!
12:05:52 <jki> alicefm: anything to add on AI #1?
12:06:36 <alicef> no
12:06:48 <jki> any other AI-related topics?
12:07:02 <jki> 3
12:07:04 <jki> 2
12:07:06 <jki> 1
12:07:08 <jki> #topic Kernel maintenance updates
12:07:24 <uli> done with 5.10.146
12:07:34 <iwamatsu> I reviewed 5.10.146 and 5.10.147.
12:07:38 <masami> This week reported 7 new CVEs and 2 updated CVEs.
12:08:03 <pave1> Reviewing 5.10.147.
12:08:30 <masami> according to the Debian security tracker, they decided to ignore CVE-2022-23816, CVE-2022-29900 and CVE-2022-29901 for buster(linux 4.19)
12:08:34 <masami> https://security-tracker.debian.org/tracker/CVE-2022-29900
12:08:43 <pave1> CVE-2022-40307 should now be patched in 4.4-cip.
12:10:19 <pave1> CVE-2022-23816,
12:10:30 <pave1> +CVE-2022-29900 and CVE-2022-29901 -- that is retpoline stuff, AFAICT.
12:10:55 <pave1> If stable takes the backports (unlikely), we
12:11:20 <pave1> will inherit them. But I don't believe we want to do much more.
12:11:32 <pave1> Complain to Intel & AMD if they sold you a buggy CPU :-(.
12:11:54 <masami> I found patch for 4.4-cip. thanks. https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/commit/?h=linux-4.4.y-cip&id=7f7838c92740fa423a5a3f12c00ed02d92851254
12:12:34 <pave1> [Intel made it clear that we can expect more of the similar bugs in future :-(.]
12:13:41 <masami> it looks was if e need a lot of effort to backport patches :(
12:13:54 <masami> s/was/as
12:14:12 <jki> I think we had the discussion already on threat scenarios for our domain when meltdown showed up
12:15:19 <jki> if we communicate clearly what we will (not) do with 4.4 here, we should be able to skip this
12:15:52 <pave1> That would be 4.4 and 4.19, if I understand that correctly.
12:17:45 <masami> mainline, 5.18, and 5.10 were fixed but 4.x series are not yet.
12:17:50 <jki> then even for 4.19 - the key question is, though, if CIP members agree that there are no use cases of untrustworthy workload aside sensitive one
12:19:21 <pave1> jki: On affected CPUs.
12:19:41 <jki> sure
12:20:23 <pave1> jki: I believe this is going to repeat in future, and perhaps we should start pointing out that "out-of-order CPUs are not suitable for protecting sensitive data".
12:22:22 <jki> which will not prevent people from designing new systems at least that will have this expectation
12:22:41 <pave1> jki: Not really. Just use CPU that is suitable for the job.
12:23:08 <pave1> There should be PowerPCs suitable, Cortex A53 & friends, most RISC-Vs.
12:23:12 <jki> in-order will not deliver you the performance you need when co-locating modern workloads
12:24:02 <jki> but this discussion is possibly a bit too fundamental for this round
12:24:15 <patersonc[m]> pave1: That doesn't help users who are in a situation where they can't just swap out the processor for 10+ years - which was kinda the original point of CIP
12:24:17 <pave1> Don't do it, then. At least Intel made it clear that security is not their priority.
12:25:02 <pave1> patersonc: True. But in control applications people are still using in-order CPUs I believe.
12:25:46 <pave1> And if you have sensitive data & untrusted userspace, then you a) should not really do that and b) at least use suitable CPU.
12:26:10 <patersonc[m]> sure
12:29:14 <jki> so, I would now inform the members about our plan to not back-port anything related at next TSC
12:29:49 <jki> any concerns about this?
12:29:53 <pave1> I guess so. -stable is not backporting it, and this would be likely a lot of work.
12:30:55 <jki> any other maintenance topics?
12:31:24 <jki> 3
12:31:26 <jki> 2
12:31:27 <jki> 1
12:31:30 <jki> #topic Kernel testing
12:33:14 <patersonc[m]> We have some issues with the gitlab runners. 1) Runners seem to be "not found", even though jobs are already running on them (thanks pavel) 2) Container builds using kaniko aren't working
12:33:31 <patersonc[m]> Our runner boss is travelling this week and will look into it more next week
12:33:34 <alicefm> Jki i just replayed to the gitlab issue about creating cip-core on KernelCI and closed it. as that work is already done.
12:34:06 <alicefm> Thanks for reminding
12:34:34 <jki> is the runner topic blocking us?
12:34:53 <patersonc[m]> jkl: I started adding risc-v build support to our gitlab CI testing setup - but was blocked by the second runner issue above
12:35:11 <patersonc[m]> s/jkl/jki/
12:35:57 <jki> let me check if someone else could help
12:36:17 <patersonc[m]> Thanks
12:36:32 <patersonc[m]> The other issue is also a pain for kernel testing in general
12:37:18 <patersonc[m]> The KernelCI testing side of things obviously isn't affected though
12:38:21 <patersonc[m]> alicef: do you know if kernelci is already testing qemu-riscv?
12:38:30 <patersonc[m]> I forgot to check
12:38:37 <alicefm> Sorry im not sure about that
12:39:57 <alicefm> https://github.com/kernelci/kernelci-core/pull/1460
12:40:18 <alicefm> There is some effort on that direction
12:40:38 <jki> but only fairly recently...
12:41:41 <alicefm> Yes is some recent effort
12:43:52 <alicefm> But will be merged soon
12:44:16 <patersonc[m]> When it is we'll enable testing on the CIP kernel
12:44:22 <patersonc[m]> s/kernel/kernels/
12:44:36 <patersonc[m]> s/kernel/kernels, assuming it works/
12:44:44 <pave1> :-)
12:44:48 <alicefm> Yes!
12:45:23 <jki> it should at least in QEMU ;)
12:46:12 <jki> but they are brave to take random sid-ports...
12:46:47 <jki> anyway - anything else on testing?
12:47:09 <patersonc[m]> I don't think so
12:47:43 <jki> 3
12:47:45 <jki> 2
12:47:47 <jki> 1
12:47:49 <jki> #topic AOB
12:47:58 <alicefm> Yes all for me also
12:50:30 <jki> no other businesses?
12:51:16 <patersonc[m]> Nope
12:51:50 <jki> then let's close in...
12:51:53 <jki> 3
12:51:56 <jki> 2
12:51:58 <jki> 1
12:52:00 <jki> #endmeeting