13:02:33 <jki> #startmeeting CIP IRC weekly meeting
13:02:33 <collab-meetbot> Meeting started Thu Aug 22 13:02:33 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:33 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:02:33 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:02:37 <jki> #topic AI review
13:02:42 <jki> - prepare blog entry on SLTS kernel state and challenges [Jan]
13:02:49 <jki> unfortunately still no news
13:02:55 <jki> - look into CVE triage tool [iwamatsu-san]
13:03:04 <iwamatsu__> I have used this tool.
13:03:21 <iwamatsu__> This is a tool to identify the CVEs involved in a given kernel config.
13:03:43 <jki> yes, or to rule CVEs out based on a config
13:03:53 <iwamatsu__> I think this is a good tool to determine which CVEs are related to our kernel configurations. However, it takes a long time to process and this needs to be improved. In my environment, it took about 25 minutes per run.
13:04:29 <iwamatsu__> The time can be reduced by having the program support parallel processing.
13:05:06 <jki> I suppose there are ways to optmize its runtime
13:05:17 <jki> did you also check the accuracy, at least for some examples?
13:06:54 <iwamatsu__> Yes, I have also checked some for accuracy. I have only checked three kernel versions, but so far I have not found any problems.
13:07:11 <iwamatsu__> And Since the results are output in JSON, the information can be filtered by processing the JSON. Currently, report-overview.py is provided as a simple tool for this.
13:07:36 <iwamatsu__> At this time, it is necessary to look at the JSON to see which CVEs have been fixed, so report-overview.py and others need to be improved.
13:08:48 <jki> makes sense
13:09:13 <jki> but this sounds to me like we should continue to drive this, improve useability and eventually actually hook it into our workflow, right?
13:10:07 <iwamatsu__> Yes,  I agree.
13:10:54 <jki> perfect, already informed Christoph :)
13:11:07 <jki> then next item
13:11:13 <jki> - clarify role of linux-6.1.y-cip-rebase tag [iwamatsu-san]
13:11:22 <jki> was this resolved?
13:12:09 <pave1> Reference would be
13:12:11 <pave1> Date: Tue, 13 Aug 2024 17:47:59 +0200
13:12:15 <pave1> Subject: Re: [cip-dev] [ANNOUNCE] v6.1.102-cip26
13:12:27 <pave1> https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/tag/?h=linux-6.1.y-cip-rebase
13:12:27 <pave1> This is _tag_ linux-6.1.y-cip-rebase. We also have a branch
13:12:28 <pave1> linux-6.1.y-cip-rebase. IMO the tag is a mistake.
13:13:51 <jki> iwamatsu__:?
13:14:21 <iwamatsu__> I am aware of this problem and try to erase it from the repository in my scripts every time. But I will check again.
13:14:47 <jki> so, this tag is re-created by a release script?
13:16:00 <iwamatsu__> No, I don't think it was created by my script....
13:16:17 <iwamatsu__> But I will recheck .
13:16:23 <jki> ok, thanks
13:16:35 <jki> would be good to understand if this is recurring
13:17:02 <jki> other AIs I don't have, so...
13:17:05 <jki> 5
13:17:07 <jki> 4
13:17:08 <jki> 3
13:17:10 <jki> 2
13:17:11 <jki> 1
13:17:13 <jki> #topic Kernel maintenance updates
13:17:30 <masami> This week reported 187 new CVEs and 11 updated CVEs.
13:17:32 <uli> been reviewing 6.1.103
13:17:53 <pave1> I'm doing reviews, 6.1.103, .106 and AUTOSEL.
13:18:34 <iwamatsu__> I reviewed 6.1.106.
13:19:34 <jki> anything else?
13:20:09 <jki> 5
13:20:10 <jki> 4
13:20:11 <jki> 3
13:20:13 <jki> 2
13:20:14 <jki> 1
13:20:15 <jki> #topic Kernel release status
13:20:23 <jki> all green this time :)
13:20:30 <arisut> nice
13:20:37 <jki> any issues ahead?
13:20:52 <arisut> kci-dev as became an official kernelci project
13:21:08 <arisut> but no updates on terms of functionality
13:21:18 <jki> you are already at "testing" :)
13:21:20 <jki> so
13:21:22 <jki> #topic Kernel testing
13:21:29 <arisut> sorry
13:21:33 <pave1> Sep 9th should see 3 -rt releases in 3 days. But no problem foreseen.
13:21:39 <arisut> thanks
13:22:06 <jki> arisut: congrats for the project promotion
13:22:14 <arisut> jki, thanks :)
13:22:29 <jki> now just finish it ;)
13:22:37 <arisut> right :)
13:23:08 <jki> we had some issues with the qemu runner in the siemens-lab, should be resolved now
13:23:27 <arisut> thaks for fixing it
13:23:53 <jki> seems it got quite some attention - unluckily
13:23:54 <pave1> It would be nice to monitor dmesg for any backtraces,
13:24:08 <pave1> in case it returns,
13:24:20 <pave1> or if similar issue should appear.
13:24:42 <jki> should be possible, we did that in some other setup, but don't ask me for the details
13:26:31 <jki> anything else on testing?
13:26:46 <fbezdeka> The problem was on the host this time, quite hard to automatically monitor that from the test infrastructure / LAVA
13:27:25 <arisut> why not using lava-docker ?
13:27:49 <fbezdeka> how would that help in case the host has a problem?
13:27:50 <jki> we are using that, but that does not protect you from hw issues of your host
13:28:00 <arisut> having lava on docker should make errors better reproducibility
13:28:14 <jki> despite rumors, you still need real hardware somewhere to run containers ;)
13:28:25 <arisut> sure hw issue are a different beast
13:28:38 <arisut> :D
13:28:54 <arisut> despite rumors lol
13:29:43 <jki> but are we catching kernel warnings of the target in lava already, or not?
13:32:08 <jki> is kernelci filtering them out? I would expect that
13:32:40 <arisut> you mean host errors?
13:33:00 <arisut> or board errors?
13:33:44 <jki> board errors
13:34:58 <arisut> yes they are filtered with the testing system
13:35:13 <jki> ok, good
13:35:20 <arisut> mostly depends on which tests are executed
13:35:30 <arisut> or allowed to be executed
13:35:58 <jki> well, they should always be filtered and reported - unless the test case is to test WARN_ON
13:36:27 <arisut> yes they should be reported
13:36:56 <jki> good, then move on...
13:36:58 <jki> 5
13:37:00 <jki> 4
13:37:01 <jki> 3
13:37:03 <jki> 2
13:37:05 <jki> 1
13:37:06 <jki> #topic AOB
13:37:33 <jki> anything else for today?
13:38:13 <csteiger> I have some questions about the triage tool
13:38:23 <csteiger> First of all thank you for checking it out :)
13:38:40 <csteiger> What would you like to have in the overview tool? Which CVE the tool deemed relevant?
13:40:37 <jki> iwamatsu__:?
13:41:15 <iwamatsu__> I would be happy to see a list of the CVEs involved and the status of the CVEs and commit ID.
13:41:49 <csteiger> That can be done
13:42:30 <jki> cool
13:42:42 <iwamatsu__> nice
13:43:07 <csteiger> About the performance: did you cache the kmax formulas for each kernel version?
13:43:14 <csteiger> Generating them takes about 5 to 10 minutes on my machine
13:44:27 <csteiger> The checks can be parallelized too I think, which should give us some improvements too
13:45:21 <iwamatsu__> I create them every time. I do not use cache. I understand that using a cache can be mitigating.
13:46:26 <jki> will those 15-25 min. run be per CVE?
13:47:05 <iwamatsu__> per a kernel config.
13:47:23 <csteiger> No, once the kmax formulas are there, which only has to be done once for each kernel version, it takes about 10 seconds per CVE
13:47:33 <csteiger> or shorter, when we do not need to run all checks
13:47:37 <jki> ok, that is better
13:48:55 <jki> anything else?
13:49:23 <jki> 5
13:49:24 <jki> 4
13:49:26 <jki> 3
13:49:27 <jki> 2
13:49:29 <jki> 1
13:49:30 <jki> #endmeeting