13:01:53 <jki> #startmeeting CIP IRC weekly meeting
13:01:53 <collab-meetbot> Meeting started Thu Aug  7 13:01:53 2025 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:53 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:53 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
13:02:01 <jki> #topic AI review
13:02:16 <jki> none on my list, and I found none in the past weeks
13:02:22 <jki> 5
13:02:24 <jki> 4
13:02:25 <jki> 3
13:02:27 <jki> 2
13:02:28 <jki> 1
13:02:31 <jki> #topic Kernel maintenance updates
13:02:43 <masami> This week reported 4 new CVEs and 8 updated CVEs.
13:02:44 <pave1> I'm reviewing 6.12.40 and 41.
13:02:45 <uli> i'm preparing 4.19
13:02:57 <iwamatsu__> I reviewed 6.12.40 and 41.
13:04:11 <jki> anything to add?
13:04:24 <jki> 5
13:04:25 <jki> 4
13:04:27 <jki> 3
13:04:29 <jki> 2
13:04:30 <jki> 1
13:04:32 <jki> #topic Kernel release status
13:04:42 <jki> all lights green right now
13:05:25 <jki> any issues upcoming?
13:05:36 <jki> 5
13:05:38 <jki> 4
13:05:40 <jki> 3
13:05:42 <jki> 2
13:05:44 <jki> 1
13:05:46 <jki> #topic Kernel testing
13:06:04 <patersonc> Arisu-san has been continuing to get our boards added to the new KernelCI
13:06:22 <arisut> I could send test to the cip boards on lava, currently going on improving the work
13:06:25 <arisut> https://lava.ciplatform.org/scheduler/alljobs?page=1&length=25&search=kci-staging#table
13:06:34 <arisut> from KernelCI
13:06:34 <patersonc> Thanks :)
13:06:57 <patersonc> It looks like not all boards boot when using the merged config
13:07:29 <patersonc> arisut please ping me if there's anything specific you'd like me to investigate
13:07:38 <jki> some examples at hand?
13:07:52 <jki> and we do have configs for them in our repo that used to boot?
13:07:55 <patersonc> jki: https://lava.ciplatform.org/scheduler/job/1298034
13:08:02 <arisut> sure, currently I just need to finalize the PR and be sure that what we expect is what we get
13:08:14 <patersonc> arisut: Thanks
13:09:12 <patersonc> Does anyone know if the 6.12 merged CIP config is meant to work with de0-nano?
13:09:54 <patersonc> Maybe we don't need to support it, depending on the blank cell in https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware#cip_reference_hardware
13:09:55 <jki> likely not yet
13:10:11 <jki> if there is no nano-soc config for 6.12 uploaded
13:10:23 <iwamatsu__> not yet
13:10:34 <jki> expected error
13:10:35 <patersonc> Maybe Arisu-san we skip nano-soc and iwg20m for 6.12?
13:11:12 <arisut> actually we could support it, one of the problem is that currently KernelCI is mixing up configurations
13:11:15 <jki> we can simply fix the config, I would say
13:11:37 <arisut> patersonc, I don't mind to push as is and improve it later
13:11:42 <arisut> same for riscv
13:11:47 <patersonc> Again it's a question of do we build/test boards not listed as reference h/w ?
13:12:23 <jki> oh, we didn't decide whether to keep the nanosoc in support, right
13:12:25 <arisut> nano is listed
13:12:30 <arisut> for v6.1
13:12:41 <arisut> and 4.19/5.10
13:13:08 <patersonc> Sure. Was it working with those branches?
13:13:26 <arisut> we currently don't know, actually
13:13:36 <arisut> as I said my PR is still in progress
13:13:41 <arisut> is not yet merged
13:14:12 <patersonc> Sure. I'd remove the not-working ones from your PR for now. Then we can add more as we test they work?
13:14:19 <arisut> and configurations are not always used as expected
13:14:47 <patersonc> arisut: Should I talk to Denys about getting me set up so I can push/test with staging? Or would it clash with your work?
13:15:09 <arisut> patersonc, currently my PR is not stable to be merged. we are still not applying the right configurations to the right boards
13:15:54 <arisut> and some configurations are not yet merged in the *-cip sub configurations
13:17:49 <patersonc> Question for the kernel team - are we currently maintaining the in-tree defconfigs for each arch?
13:18:32 <jki> which defconfigs? those inside the kernel tree? they are per-arch, obviously
13:18:55 <pave1> That's iwamatsu-san question, but I don't believe we touch those configs.
13:19:39 <pave1> ...or actually...
13:19:58 <pave1> ...we are getting patches to arch/arm64/configs/defconfig when the driver is merged, etc,
13:20:04 <pave1> and we merge those patches.
13:20:14 <pave1> I guess you could call that "maintaining" :-)
13:20:39 <jki> yeah, would be strange to see normal stable fixes touching those defconfigs
13:21:10 <patersonc> Okay. Then I'll aim to include defconfig builds in the kernelci setup
13:21:42 <patersonc> I think it's worth making sure they at least build - as I assume a lot of users would use them as a first step
13:21:51 <pave1> Actually, that happens, too. 72ce323e17d0f6a6d586cdded4dc38cdcba31b6d . It should not, but when stable
13:22:18 <pave1> team picks up dependencies for a fix, they tend to pick lot of interesting stuff.
13:24:17 <arisut> My PR is currently not finished, at this time working on a unfinished PR would clash with my work as the code could change later on
13:24:53 <patersonc> Sure
13:26:10 <pave1> patersonc: The way I see renesas updates .. I'd say their goal is for defconfig to boot / work on that hardware.
13:26:35 <patersonc> Yea
13:27:05 <pave1> So.. yes, I'd say testing it builds an boots would be useful.
13:27:12 <patersonc> Okay
13:28:39 <arisut> another question is if we want also to test mainline kernel on the cip boards or only cip kernel?
13:29:00 <arisut> as sometime mainline kernel could be useful as reference
13:29:06 <pave1> Older -stable kernels may not work on all cip boards.
13:29:21 <pave1> Where it works, it is useful to make sure it keeps working.
13:29:27 <pave1> So that we catch bugs early.
13:30:09 <patersonc> Agreed. Should that can be part of the standard Maestro though rather than the CIP yaml files Arisu?
13:30:29 <arisut> sure
13:30:57 <patersonc> I'm happy for the boards to be used for any KernelCI testing - part of CIP's contribution etc.
13:31:24 <arisut> actually I'm not sure what is better, I think they are still cip board
13:31:48 <arisut> so having them in one cip file is still better, if we want to do some changes
13:32:04 <jki> can we prioritize board usage?
13:32:23 <arisut> maybe I don't remember sorry
13:32:36 <arisut> but that is a good question
13:32:43 <jki> we should give boards into general testing, but if they become "overused", cip should be first
13:32:52 <arisut> right
13:33:25 <arisut> will check if is possible
13:33:37 <patersonc> Sure. We can investigate/add support once we start having capacity issues :)
13:34:56 <jki> anything else on testing?
13:35:23 <jki> 5
13:35:25 <jki> 4
13:35:26 <jki> 3
13:35:28 <jki> 2
13:35:30 <jki> 1
13:35:32 <jki> #topic AOB
13:35:54 <patersonc> o/     I have an AOB about CVEs
13:36:18 <jki> go ahead
13:36:37 <patersonc> Do we have a process for monitoring the CVEs that get created to see if they should be applied to our self-maintained SLTS kernels?
13:36:51 <patersonc> I assume that stable will sort out the LTS based kernels?
13:37:20 <patersonc> But is someone looking at each CVE "fix" and seeing if it should be backported to 4.4 and 4.19?
13:37:25 <pave1> Not sure that assumption is correct :-)
13:37:34 <patersonc> pave1: Sure :P
13:38:22 <pave1> When patch fails to apply to our -cip kernels, we take a look if it looks serious.
13:38:39 <pave1> CVEs is just another ID for patches.
13:38:48 <pave1> So yes, we kind of do that.
13:38:58 <iwamatsu__> I checked CVEs sometime, and backport.
13:39:14 <patersonc> So we don't have a mechanism as part of cip-kernel-sec?
13:39:43 <patersonc> I ask, because a couple were flagged to me recently
13:39:45 <pave1> But stable team may not backport patch if it looks too complex or does not look like serious-enough problem.
13:40:42 <patersonc> Here's an example: https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/blob/master/issues/CVE-2025-21917.yml. It's been labelled as introduced in v3.0-rc1, and "fixed" in CIP 5.10 onwards. But no "fix" in 4.4 and 4.19
13:40:59 <iwamatsu__> We are still stuck with CVE management, and we don't have a process for how to deal with unfixed CVEs.
13:41:25 <jki> we tried to filter at least irrelevant CVEs based on our configs
13:41:51 <jki> irrelevant = not used in CIP configurations, thus not officially supported
13:42:16 <pave1> I'm sure you can find many more such issue. Greg ~ automatically creates CVE for each stable patch.
13:42:16 <patersonc> We have these yaml files - is there a way to compare the "introduced-by" with the "fixed-version" fields?
13:42:51 <patersonc> iwamatsu__: Sure. But this example hasn't been marked as "irrelevant"
13:43:02 <pave1> For the CVE-2025-21917, look at the description, and note that it does not describe anything.
13:43:27 <pave1> So yes, you can (probably) run some kind of script.
13:43:33 <pave1> You'll get 1000+ results.
13:43:38 <pave1> Then you can laugh... or cry :-).
13:44:36 <jki> tooling and maintenance capacity need to be increased to track CVEs on "paper", with VEX output or whatever
13:45:07 <iwamatsu__> I thought it might be necessary to keep a record of checking for unfixed CVEs as CIP.
13:45:35 <iwamatsu__> I am checking CVEs via web interface
13:45:46 <jki> we have the KNOWN-BUGS file, but that is only for prominent ones
13:46:11 <pave1> Yeah, putting every single CVE would make that file completely useless.
13:46:27 <pave1> Yeah, putting every single CVE there would make that file completely useless.
13:47:02 <patersonc> Maybe we need to first work out which CVEs aren't fixed, then work out how many could be easily.
13:47:09 <jki> we should probably discuss the existing process and possible enhancements/costs during the extended meetup
13:47:24 <patersonc> jki: Good shout
13:47:25 <iwamatsu__> Can we use cip-kernel-sec?
13:47:33 <patersonc> Makes sense to me
13:47:43 <jki> there is no "just do X" or "just spend some extra hour" to address this
13:47:58 <pave1> If you want to see log of various patches not backported
13:48:06 <pave1> ...which is basically CVEs...
13:48:21 <pave1> ...you can take a look at v4.4.org and v4.19.org
13:48:35 <pave1> in git@gitlab.com:cip-project/cip-kernel/lts-commit-list.git repository.
13:48:53 <pave1> That's where the work is recorded.
13:49:05 <arisut> makes sense
13:49:22 <pave1> There's aproximately 9000 patches not applied to 4.4, and 1500 not applied to 4.19.
13:50:42 <pave1> (that was wc, so its less than that, but you get the idea).
13:51:14 <pave1> (7000 and 1000).
13:54:19 <jki> let me try to prepare some discussion about that for Amsterdam
13:54:38 <jki> do we have some material to start from?
13:55:55 <patersonc> uli did you present a bit about the CVE tools a while back?
13:56:03 <pave1> I did take 9 randomly selected CVEs and tried to review them at one point.
13:56:25 <uli> patersonc: not specifically, it was about the maintenance process in general
13:56:36 <patersonc> okay
13:56:37 <uli> actually only mentioned cves when somebody asked about it :)
13:57:05 <jki> yeah, these questions will increase...
13:57:25 <jki> anyway, will share with you upfront for alignment
13:57:34 <jki> anything else for today?
13:57:43 <iwamatsu__> I'm on vacation next week.
13:58:23 <jki> ok
13:58:28 <jki> enjoy :)
13:58:38 <iwamatsu__> :-)
13:58:52 <pave1> I decided 3 were not security issue, one could not be determined in reasonable time, 2 were "ok, maybe that should be fixed", rest was "that's really low severity".
14:00:13 <jki> ok, let's close...
14:00:16 <patersonc> For CVEs we've spotted like this, should we backport the patch and send to cip-dev? How does cip-kernel-sec then get updated?
14:00:53 <pave1> patersonc: If you believe you see a real security issue that's "bad" and want it fixed...
14:01:01 <pave1> yes, backport, cip-dev and uli.
14:02:00 <patersonc> Okay
14:02:04 <pave1> Please have real description of a bug ("uid 123 can echo baz into /sys/foo to crash the system").
14:02:07 <masami> if patch is merged into git repo, cip-kernel-sec can be updated.
14:02:26 <patersonc> Thanks masami
14:02:42 <jki> great! but I suspect too much manual work still ;)
14:02:52 <jki> ok... anything else?
14:03:10 <jki> 5
14:03:11 <jki> 4
14:03:13 <jki> 3
14:03:15 <jki> 2
14:03:17 <jki> 1
14:03:18 <jki> #endmeeting