13:02:48 <jki> #startmeeting CIP IRC weekly meeting
13:02:48 <collab-meetbot`> Meeting started Thu May 23 13:02:48 2024 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:48 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:02:48 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
13:02:55 <jki> #topic AI review
13:03:07 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:03:34 <jki> down in the prio list again, was struggling (and still are) with cip-core
13:03:51 <jki> no other AIs recorded
13:03:57 <jki> 5
13:03:58 <jki> 4
13:04:00 <jki> 3
13:04:01 <jki> 2
13:04:02 <jki> 1
13:04:05 <jki> #topic Kernel maintenance updates
13:04:23 <pave1> I was reviewing 6.1.91.
13:04:24 <uli_> i'm back from vacation, nothing substantial to report yet
13:04:25 <masami> This week reported 685 new CVEs and 8 updated CVEs.
13:04:29 <iwamatsu__> I am reviewing 6.1.91
13:05:20 <jki> 685 is a new record - any particular reason for that peak visible?
13:06:07 <masami> not sure..
13:07:16 <jki> just curious, not that it would change the overall situation
13:07:21 <pave1> Shal we do anything with the CVEs?
13:08:05 <pave1> I went through some, and signal-to-noise is not quite usefu
13:08:11 <pave1> useful.
13:08:27 <jki> well, we can only do automated stuff with them, given the amount
13:08:57 <pave1> We are automatically putting them into database noone reads
13:09:13 <jki> can we filter out anything that we already got or that is not affecting older kernels?
13:09:30 <jki> to have stats of potentially open issues, at least on the CVE paper?
13:10:42 <pave1> I believe we have similar information in better form already
13:11:32 <pave1> cves are just git dumps. Not sure what kind of paper would be useful to generate from that.
13:11:39 <arisut> pave1: what are you referring to?
13:12:26 <pave1> arisut -- greg is copy-pasting git logs into cves.
13:13:02 <masami> Investigating issues where the commit introducing the bug is not documented. Perhaps we should focus on such bugs?
13:14:33 <pave1> Masami -- commit introducing not known will be common.
13:14:55 <jki> well, anything that is fix in X, affecting Y and possibly not even affecting CIP is not interesting, sure
13:15:18 <jki> digging into details is likely not helpful beyond examples
13:15:23 <pave1> but maybe we could filter by commit fixing not listed, because those are not spam?
13:15:25 <jki> having stats could be
13:15:52 <pave1> jki -- i have some stats.
13:16:22 <pave1> on very small sample 50% is simply not security related.
13:16:42 <pave1> 40% may be relevant in some crazy config.
13:17:05 <jki> well, config correlation is another area of interest, if automatable
13:17:05 <pave1> 10% could be a real issue.
13:17:32 <jki> you may have seen https://ciq.com/blog/why-a-frozen-linux-kernel-isnt-the-safest-choice-for-security/
13:17:52 <jki> and the fact that they didn't look at the configs
13:18:21 <pave1> I can take a look. I believe that's more broken than that.
13:18:22 <patersonc> jki: I guess we don't know _every_ config a SLTS user will be using though? Unless there are some options that can _never_ be used?
13:18:37 <jki> we have defined supported configs
13:18:44 <jki> we are not supporting random ones
13:19:20 <jki> those can be debated in details, but if we exclude drivers or complete subsystems, that are easy takes (or non-takes)
13:19:50 <patersonc> What happens if a new member joins and adds more configs? We would have to go back and work out which CVEs are now relevant, which we couldn't do if they weren't in our database to start with?
13:20:16 <patersonc> Anyway, this topic is probably worth a proper call/F2F about at some point?
13:20:34 <jki> that is a valid point, and it would at least take some impact analysis, automated
13:21:22 <jki> if we exclude CVE-0815 today, will adding CONFIG_Y bring it plus hundreds more in?
13:21:35 <jki> so far, we cannot tell that
13:21:53 <jki> and no one is able to do manual analysis
13:21:56 <pave1> Well, we pretend we support any config on supported architectures.
13:22:06 <jki> nope, we surely don't
13:22:14 <jki> we never
13:22:49 <jki> CIP is not a distro kernel, and even distros have certain exclusion areas, starting with CONFIG_STAGING
13:23:06 <pave1> ok, sure, staging is out.
13:25:15 <jki> and more, just look at an long-living enterprise kernel
13:25:54 <jki> do not state that CIP is generic, please, that is neither true nor what we communicated all the time
13:26:24 <jki> we may patch left and right, but only on best effort basis, if at all
13:26:52 <pave1> I guess we should create a list of 'definitely out' options at some point.
13:27:18 <jki> how to maintain that?
13:27:34 <jki> it would not be a technically executable something
13:27:44 <jki> we have a whitelist, and members can expand it
13:28:00 <jki> we need to take measure to assess expansion requests better
13:30:15 <jki> likely a topic for next TSC as well...
13:30:29 <jki> anything else about this or beyond on maintenance?
13:31:10 <jki> 5
13:31:12 <jki> 4
13:31:13 <jki> 3
13:31:14 <jki> 2
13:31:16 <jki> 1
13:31:19 <jki> #topic Kernel release status
13:31:32 <jki> I saw 4.19-rt is out
13:31:40 <jki> 6.1 is scheduled?
13:31:43 <iwamatsu__> I am working for 6.1.y-cip
13:32:02 <jki> perfect
13:32:07 <jki> anything else?
13:32:26 <jki> 5
13:32:28 <jki> 4
13:32:29 <jki> 3
13:32:31 <jki> 2
13:32:32 <jki> 1
13:32:34 <jki> #topic Kernel testing
13:33:02 <patersonc> We had some gitlab runner token issues, resolved now. Sorry for the interruption Pavel
13:33:28 <arisut> no news from me
13:33:34 <patersonc> I've been looking into some cip core testing bits & bobs.
13:33:39 <patersonc> That's about it
13:33:57 <pave1> no problem, it works now
13:34:26 <jki> Siemens lab bring-back is delayed due to connectivity issues
13:34:34 <patersonc> I've been trying to push internally for more time/resources to work on CIP testing - the project is well behind where it should be. We need to get a lot more in place before more LTS kernels go EOL and everyone jumps to SLTS...
13:34:39 <patersonc> Thanks jki
13:34:41 <jki> discussed with Quirin today, we have a resolution strategy now
13:35:12 <jki> patersonc: thanks for bringing this up! so true
13:37:27 <patersonc> I guess there's nothing else for testing this week...
13:38:27 <jki> ok, then moving on...
13:38:33 <jki> 5
13:38:35 <jki> 4
13:38:37 <jki> 3
13:38:39 <jki> 2
13:38:41 <jki> 1
13:38:44 <jki> #topic AOB
13:39:22 <jki> iwamatsu__: there are quite a few open MRs on the config repo - already had time to check?
13:39:44 <jki> specifically the x86 generic one would help to also move forward with isar-cip-core
13:40:15 <iwamatsu__> I am reviewing now, so I think I can merge it tomorrow.
13:41:03 <jki> great, TIA!
13:41:23 <jki> other topics?
13:41:45 <jki> just checking: next week is public holiday again for me
13:42:00 <jki> I may not be available
13:42:58 <pave1> I have something just before....
13:43:31 <pave1> ...but there's good chance it ends in time.
13:43:42 <iwamatsu__> I can takeover.
13:43:44 <patersonc> I won't be here next Thursday, apologies
13:44:18 <jki> ok, if the round becomes too small, make it short or skip directly
13:44:38 <jki> but thanks for your offer, iwamatsu-san
13:44:52 <iwamatsu__> :)
13:45:47 <pave1> So cancel or keep?
13:48:08 <iwamatsu__> If there are few participants, I think it is okay to cancel.
13:48:16 <jki> looks like
13:48:27 <arisut> ok for me too
13:48:35 <uli_> i'm ok either way
13:48:39 <jki> use email for anything urgent to discuss
13:48:46 <arisut> yeah me too
13:48:50 <masami> ok
13:49:56 <pave1> Ok, so next one is cancelled. See you in 14 days.
13:50:22 <jki> good
13:50:23 <arisut> see you pave1
13:50:30 <jki> then closing for today...
13:50:40 <jki> 5
13:50:42 <jki> 4
13:50:43 <jki> 3
13:50:44 <jki> 2
13:50:46 <jki> 1
13:50:48 <jki> #endmeeting