13:00:57 <jki> #startmeeting CIP IRC weekly meeting 13:00:57 <collab-meetbot> Meeting started Thu Mar 10 13:00:57 2022 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:57 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:57 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting' 13:00:57 <brlogger`> Meeting started Thu Mar 10 13:00:57 2022 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:57 <brlogger`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:57 <brlogger`> The meeting name has been set to 'cip_irc_weekly_meeting' 13:01:00 <jki> hi! 13:01:06 <uli> hello 13:01:08 <iwamatsu> hi 13:01:12 <masami> hello 13:01:28 <pave1> hi! 13:03:26 <josiah> Hi 13:04:28 <patersonc[m]> Hello 13:04:55 <jki> ok, let's go 13:05:08 <jki> #topic AI review 13:05:12 <jki> 1. Resolve/filter irrelevant failures of KernelCI for 4.4-cip - patersonc & alicefm 13:06:18 <patersonc[m]> Sorry, nothing done yet 13:06:32 <jki> 2. Add 4.9-stable-rc to testing - patersonc 13:06:55 <patersonc[m]> I started this 13:07:09 <patersonc[m]> We're missing three configs from cip-kernel-config for 4.9 13:07:19 <patersonc[m]> Other then that things are working 13:07:21 <pave1> ...and it gave first results. Thanks! 13:07:59 <patersonc[m]> Do we know if any more boards are supported natively in 4.9 compared to 4.4? 13:08:25 <patersonc[m]> iwamatsu: Ah I've just seen your email about the configs. Thank you 13:09:09 <jki> so this topic can be considered done? 13:09:26 <iwamatsu> patersonc: sorry about it. 13:09:27 <patersonc[m]> I need to merge, but essentially all is in place 13:09:39 <jki> perfect 13:10:17 <jki> anything else before moving on? 13:10:29 <jki> 3 13:10:32 <jki> 2 13:10:34 <jki> 1 13:10:37 <jki> #topic Kernel maintenance updates 13:11:30 <pave1> I did some reviews on 5.10.104 and 105. Working on scripts for self-maintainance. 13:11:32 <uli> reviewing 5.10.104 13:11:35 <masami> This week reported 12 new CVEs and 3 updated CVEs. 13:11:42 <masami> Dirty Pipe and BHI (Spectre-BHB) are notable issues. 13:12:39 <iwamatsu> I could not kernel review work this week. 13:13:03 <jki> Spectre-BHB is arm64, right? what about that AMD spectre issue? 13:14:10 <masami> intel and amd cpus are affected 13:14:30 <pave1> If there's good summary of the spectre issues, I'd like to know. 13:14:34 <iwamatsu> Do we need to release 5.10.Y-cip for fixing those CVEs? 13:14:51 <jki> more than likely 13:15:13 <jki> I have more and more user with "apps" on their machines, thus not only with fully trusted code 13:15:46 <patersonc[m]> pave1: There are some links to summaries on here: https://lwn.net/Articles/887326/ 13:16:11 <pave1> patersonc: Thank you! 13:16:47 <masami> PoC is on the github https://github.com/vusec/bhi-spectre-bhb 13:16:58 <jki> this is really limited to eBPF? 13:19:17 <jki> hmm, the exploit PoC does not look like bpf 13:19:30 <masami> It looks like eBPF is one of the methods to abuse this bug. 13:20:07 <pave1> jki: The FAQ at https://www.vusec.net/projects/bhi-spectre-bhb/ says eBPF makes it easier, but should not really be a requirement. 13:20:31 <jki> ok (or not) - then we should better fix soon 13:21:00 <pave1> jki: Well, well well. I'll get you a hammer and you can smash all the affected CPUs? :-) 13:21:23 <jki> need to have a long shaft ;) 13:21:39 <pave1> jki: I mean, we can't really _fix_ that. Those CPUs are broken. We can apply workarounds but bug will re-surface. 13:21:50 <jki> likely 13:22:01 <pave1> :-(. 13:22:08 <jki> but this isssue is also one of those with high public attention 13:22:32 <pave1> We can hand out more hammers :-). 13:22:45 <pave1> I guess we should make a release once 5.10.105 is out? 13:23:08 <patersonc[m]> Doesn't affect RISC-V :) 13:23:34 <jki> let's see when that will change ;) 13:23:44 <iwamatsu> +1 13:23:49 <pave1> patersonc: There are few high-performance RISC-V CPUs. So that may not really be good news for RISC-V. 13:23:50 <jki> so, 5.10.105 will be the first to have these "workarounds"? 13:24:09 <jki> pavel: exactly... 13:24:32 <patersonc[m]> pave1: :) 13:24:35 <pave1> dirty pipe is fixed in 5.10.103 or so. Speculation workarounds are being reveiewed for 5.10.105-rc1. 13:24:57 <fbezdeka> According to the -rc candidate Greg posted earlier today 5.10.105 will hold such "workarounds" 13:25:41 <jki> are we ready to release quickly after upstream? 13:25:57 <jki> or should we better move forward to clean the dirty pipe? 13:26:57 <jki> granted, that one is easy to fix locally if users are in a hurry 13:27:12 <pave1> 5.10.105 can be expected this Friday or next Monday, I'd say. 13:27:57 <fbezdeka> "Responses should be made by Fri, 11 Mar 2022 15:58:48 +0000." 13:29:52 <jki> so, what are the opinions? 13:30:11 <iwamatsu> I think that local fixes mean a fork, so it is not a good way. 13:31:24 <pave1> I believe one release based on 5.10.105 should be enough. 13:31:24 <iwamatsu> I would like to wait for 5.10.105. 13:31:56 <masami> +1 to wait for 5.10.105 13:32:28 <jki> ok, but then let's communicate this to the list 13:33:23 <pave1> iwamatsu: You have script modifying wiki when new -rc is out? Could that be suspended for now? 13:34:02 <pave1> I'll simply manually update it when uli tells us that he's about to run out of work. 13:34:40 <iwamatsu> pave1: ok, I will suspend it. 13:34:52 <pave1> Thank you! 13:36:39 <iwamatsu> suspended now. 13:37:04 <pave1> Wow, that was quick. Thanks! 13:40:11 <pave1> ...mov on? 13:40:17 <jki> btw, someone read https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/blob/master/issues/CVE-2022-0847.yml and was confused that 4.19 was not in the ignore list 13:42:24 <masami> jki: 4.19 had uninitialized bug too. 13:43:22 <masami> so, 4.19 is in fixed-by list. 13:43:22 <jki> but not the CVE 13:43:46 <jki> ok, anyway, I explained this (more than once) 13:43:58 <masami> ah, yes. 13:44:09 <jki> then let's move on 13:44:10 <masami> I will update it. 13:44:27 <jki> thanks! 13:44:33 <jki> #topic Kernel testing 13:45:14 <patersonc[m]> As you know I looked at 4.9.y-rc testing 13:45:23 <patersonc[m]> Other then that not much to report 13:46:12 <jki> ok - anything else on testing by others? 13:47:04 <jki> 3 13:47:06 <jki> 2 13:47:07 <jki> 1 13:47:09 <jki> #topic AOB 13:47:45 <jki> looks like LF actually changed the directory layout of the logger for us! 13:47:48 <patersonc[m]> Are we aiming for a new 4.19-rt release any time soon? Someone pointed out to me that it's been 3 months since the last one 13:48:35 <pave1> patersonc: in february, we did not get matching 4.19-cip and 4.19-rt releases. We should get that in March. 13:48:52 <jki> I think we need to reconsider this 13:49:06 <jki> when the gap becomes so large and, thus, unpredictable 13:49:34 <jki> pavel: did you try in the past to rebase rt queues? 13:49:46 <patersonc[m]> Can we try and base the cip releases on what is available from rt-stable? 13:50:17 <pave1> jki: I tried at some point, and it did not work well. 13:50:33 <jki> 4.4 or 4.19? 13:50:37 <jki> or both? 13:50:51 <pave1> jki: it is quite possible it would work other times. 13:51:04 <jki> yes, I would assume so as well 13:51:42 <jki> alternative: release (extra) CIP kernels that match 13:52:06 <pave1> alternative: Adjust -cip releases to match -rt releases. 13:52:07 <jki> but waiting 3 months for that to happen by chance is not that optimal 13:53:14 <pave1> Let me check 4.19-rt releases. 13:53:29 <pave1> For 4.4-rt, we'll have to self-maintain, so .. that will be way more fun. 13:53:57 <jki> sure - and no "excuses" ;) 13:54:27 <jki> if there is additional effort involved, let's discuss how to tackle it 13:54:34 <pave1> 4.19-rt releases are happening about twice a month. 13:54:55 <pave1> Last one is Linux 4.19.232-rt104 from Mar 4. 13:55:18 <pave1> I believe we decided to do 4.190-rt once per two months? 13:56:32 <pave1> Easy solution from my side would be to wait for 4.19-rt when releasing 4.19-cip, at least every other month, so we get match for easy release. 13:57:07 <jki> ...unless there are prominent CVEs pending 13:57:47 <jki> I would rather vote for having an extra regular -cip release when in doubt 13:58:02 <jki> provided we are ready from review and testing perspective 13:58:14 <jki> but if we aren't we can't release a -rt either 13:58:24 <pave1> Yes, we may want to speed up with CVEs. 13:59:17 <pave1> Most of speculation fixes will _not_ be in 4.19.234. They should make it to the next one. 13:59:49 <pave1> But with -rt releases in the picture, that becomes kind of gamble :-(. 14:01:16 <jki> CVE trumps -rt 14:01:49 <jki> once rt caught up, we could do another regular cip release and a corresponding -rt 14:02:11 <jki> if nothing urgent is in the queue, we try to sync both releases carefully 14:02:14 <pave1> Yes, we can always solve problem with more -cip releases :-). 14:02:40 <pave1> So the latest 4.19-rt is 4.19.232-rt104. 14:02:46 <jki> whatever is optimal under speed AND effort constraints :) 14:03:03 <pave1> 4.19.235 is likely to have speculation fixes. 14:04:20 <pave1> I'd suggest to wait for next 4.19-rt and do both -cip and -rt releases...? 14:06:45 <jki> well, our beloved CVEs get resolved earlier, I would not delay the regular -cip release - but maybe we will be lucky this time 14:08:03 <pave1> Right, if 4.19.235 is out with the fixes and -rt release is nowhere around, we may need to act, anyway. 14:08:49 <jki> ok - anything else, on this or beyond? 14:09:37 <jki> if not... 14:09:40 <jki> 3 14:09:42 <jki> 2 14:09:44 <jki> 1 14:09:46 <jki> #endmeeting