| *** monstr <monstr!~monstr@nat-35.starnet.cz> has joined #cip | 05:52 | |
| *** rajm <rajm!~robert@82.27.50.32> has joined #cip | 06:59 | |
| *** frieder <frieder!~frieder@40-179-142-46.pool.kielnet.net> has joined #cip | 07:43 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.85> has quit IRC (Remote host closed the connection) | 09:07 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.85> has joined #cip | 09:07 | |
| *** shoragan_ is now known as shoragan | 10:33 | |
| *** monstr <monstr!~monstr@nat-35.starnet.cz> has quit IRC (Ping timeout: 252 seconds) | 11:56 | |
| *** iwamatsu__ <iwamatsu__!~iwamatsu_@2405:6581:5360:1800:7a44:f1a9:81f2:2da2> has joined #cip | 12:57 | |
| *** jki <jki!~jki@62.156.206.8> has joined #cip | 13:02 | |
| jki | hi all | 13:02 |
|---|---|---|
| jki | sorry for the delay... | 13:02 |
| uli | hello | 13:02 |
| arisut | hi | 13:02 |
| pave1 | Hi! | 13:02 |
| iwamatsu__ | hi | 13:03 |
| jki | ok, let's start | 13:04 |
| jki | #startmeeting CIP IRC weekly meeting | 13:04 |
| collab-meetbot` | Meeting started Thu Mar 14 13:04:30 2024 UTC and is due to finish in 60 minutes. The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:04 |
| collab-meetbot` | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:04 |
| collab-meetbot` | The meeting name has been set to 'cip_irc_weekly_meeting' | 13:04 |
| *** collab-meetbot` changes topic to " (Meeting topic: CIP IRC weekly meeting)" | 13:04 | |
| jki | #topic AI review | 13:04 |
| *** collab-meetbot` changes topic to "AI review (Meeting topic: CIP IRC weekly meeting)" | 13:04 | |
| jki | - prepare blog entry on SLTS kernel state and challenges [Jan] | 13:04 |
| jki | no relevant progress yet :( | 13:05 |
| jki | - migrate kernelci bot reports away from cip-dev [Chris] | 13:05 |
| *** masami <masami!~masami@FL1-219-107-72-235.tky.mesh.ad.jp> has joined #cip | 13:05 | |
| jki | looks to me like they are really off now | 13:05 |
| masami | hi. | 13:05 |
| jki | maybe chris will join later | 13:05 |
| jki | other AIs? | 13:06 |
| jki | 5 | 13:06 |
| jki | 4 | 13:06 |
| jki | 3 | 13:06 |
| jki | 2 | 13:06 |
| jki | 1 | 13:06 |
| jki | #topic Kernel maintenance updates | 13:06 |
| *** collab-meetbot` changes topic to "Kernel maintenance updates (Meeting topic: CIP IRC weekly meeting)" | 13:06 | |
| uli | i released 4.4-cip85 and reviewed 6.1.80 | 13:06 |
| masami | This week reported 5 new CVEs and 8 updated CVEs. | 13:06 |
| iwamatsu__ | I reviewed 6.1.80, and reviewing 6.1.81. | 13:06 |
| pave1 | I'm doing reviews -- 6.1.81 and .82. | 13:07 |
| jki | so few CVEs - something broken in the new process?? :) | 13:07 |
| masami | not sure :( | 13:08 |
| pave1 | And useful CVEs, wow. | 13:08 |
| *** fbezdeka <fbezdeka!~flo@2a02:810d:8780:7fc:714b:7d2b:a26b:4d1a> has joined #cip | 13:08 | |
| pave1 | Anyway, I believe we should not get too used to it. | 13:08 |
| jki | we need to observe closely, yes | 13:09 |
| jki | we can't draw final conclusions yet, that is for sure | 13:09 |
| masami | fyi: https://lore.kernel.org/all/20240311150054.2945210-2-vegard.nossum@oracle.com/ | 13:10 |
| jki | need to read, looks interesting | 13:11 |
| pave1 | masami: I seen that one, but I am not really sure what it means. | 13:11 |
| masami | it will describe what is vulnerability so I hope it improves kernel cve process. | 13:13 |
| jki | can we actively (and visibly) contribute to it? | 13:14 |
| pave1 | This might be good place to someone from security team to take a look. | 13:15 |
| jki | worth at least a try, but I'm already afraid they won't have the bandwidth | 13:16 |
| patersonc | I saw an interesting CVE this week... | 13:16 |
| patersonc | https://lore.kernel.org/linux-cve-announce/2024022840-CVE-2021-47050-5ba5@gregkh/T/ | 13:16 |
| patersonc | It was released e/Feb | 13:16 |
| patersonc | But the original issue was fixed a couple of years ago | 13:16 |
| patersonc | Are they now going through every bug in history? | 13:16 |
| pave1 | Yes, basically. | 13:16 |
| jki | seems like - would explain the initial peak | 13:17 |
| patersonc | But surely there would be thousands and thousands? Not just hundereds? | 13:17 |
| pave1 | Notice that: | 13:17 |
| pave1 | They don't describe the vulnerability. | 13:17 |
| pave1 | Sentence in description is incomplete. | 13:17 |
| pave1 | And this is not security vulnerability by any means. | 13:18 |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.85> has quit IRC (Ping timeout: 260 seconds) | 13:18 | |
| patersonc | Interestingly as well, this issue actually affects CIP 4.19 | 13:19 |
| patersonc | So there was some value in this - we wouldn't have realised otherwise | 13:19 |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.85> has joined #cip | 13:20 | |
| pave1 | What value do you see? | 13:20 |
| pave1 | This is robustness against bad device tree. Not any kind of security hole. | 13:20 |
| patersonc | Well, we have a NULL pointer dereference we can fix | 13:20 |
| patersonc | The point is, we're not picking up bug fixes in the CIP kernels that are fixed in LTS etc. Isn't that the point of CIP SLTS? | 13:21 |
| pave1 | 1) this does not fix anything | 13:22 |
| pave1 | 2) it may even be buggy. How does it fix the null deref? | 13:22 |
| pave1 | 3) we can't really backport all the ... that gets put into the stable tree. | 13:22 |
| pave1 | 4) now we'll have to explain people (as I'm now explaining to you) that some CVEs are jun | 13:22 |
| pave1 | junk | 13:22 |
| pave1 | :-(. | 13:22 |
| patersonc | So are we not monitoring upstream or LTS for (potential) bug fixes that affect the code we have in SLTS? Or are you saying that this patch has already been evaluated and deemed not valid for CIP? | 13:24 |
| pave1 | We are not evaluating patches to backport between 5.10 and 4.19. | 13:24 |
| pave1 | (And besides, after short evaluation, the patch is junk). | 13:24 |
| jki | not scanning for LTS-only patches may actually be a current gap | 13:25 |
| jki | will become smaller when LTS gets shorted, but we should think about that | 13:25 |
| pave1 | We relly on -stable team to do the evaluations, and they clearly did not do good job there. | 13:25 |
| pave1 | This patch should not have been in -stable in the first place. | 13:25 |
| jki | yes, don't disagree on the concrete patch | 13:26 |
| jki | it's more about the general process | 13:26 |
| patersonc | indeed | 13:26 |
| pave1 | But about 30% of patches in stable are "this does not fix anything" | 13:26 |
| jki | are we sure we will most likely catch all LTS patches for our own kernels, even if they enter later in LTS? | 13:26 |
| pave1 | and Greg does not really listen to feedback unless patch is obviously broken. | 13:27 |
| pave1 | Feel free to get him to revert this one :-). | 13:27 |
| patersonc | If we don't trust LTS at all, shouldn't we be monitoring all of the bug fixes etc. going into mainline to determine what's "correct" for CIP? | 13:27 |
| pave1 | That's what SUSE does. They get much less patches to work with. But the CVE numbers will make their job harder. | 13:28 |
| pave1 | jki: ? | 13:28 |
| pave1 | jki: We rely on stable team to maintain 6.1, 5.10 and 4.19 | 13:28 |
| pave1 | jki: Between 4.19 and 4.4, we apply "whatever applies" without much review | 13:29 |
| pave1 | jki: And then take manual look at the rest. | 13:29 |
| jki | ok | 13:29 |
| pave1 | But this patch is a) bad, and b) much less severity than we would bother manually backporting it. | 13:29 |
| patersonc | Okay. | 13:30 |
| pave1 | Its actually not okay, | 13:30 |
| patersonc | But then it circles back to the original issue - there are now unresolved CVEs for SLTS that users will want to know why aren't fixed... | 13:30 |
| pave1 | because now we'll have much more questions "why do do you have CVE-x-y unfixed". | 13:31 |
| patersonc | heh | 13:31 |
| jki | yes, our (CIP in general) effort will likely shift a bit (or more) from doing to explaining/documenting | 13:31 |
| pave1 | patersonc: Yes. And I guess someone should do a blog post | 13:31 |
| pave1 | "Greg is spamming CVE numbers with junk, that's why you see so many unfixed CVEs". | 13:31 |
| pave1 | Even better would be to contest junk CVEs such as this one. | 13:32 |
| pave1 | It might be worth using our LF contacts to stop junk comming into CVE database in the first place. | 13:33 |
| pave1 | Because I somehow suspect contesting the CVEs will nto be easy. | 13:34 |
| jki | we still need to wait a bit to let the system settle | 13:34 |
| jki | yes, these discussions at least cost a lot of time | 13:34 |
| patersonc | Regardless of the CVEs and LTS, pave1 are you suggesting that that commit shouldn't have been accepted upstream to start with? Wouldn't that solve the whole loop (going forward..) | 13:35 |
| pave1 | jki: I guess it is more diplomatic to wait. But we'll have few thousand CVEs people will ask about. | 13:35 |
| pave1 | patersonc: Yes, upstream should have rejected. | 13:36 |
| pave1 | But I don't see how that helps us. | 13:36 |
| pave1 | Plus of course -stable team should have rejected it. | 13:36 |
| jki | collect data, persistent examples (the original ones are not rejected), and then we may act | 13:36 |
| pave1 | And then they should realized this should not have CVE... | 13:37 |
| pave1 | But I'm under impression that -stable team would not revert the patch even after feedback -- because it is already in and does not hurt. | 13:37 |
| patersonc | And it would really break the CVEs to revert the "fixes" to the CVEs :P | 13:38 |
| jki | we can't argue based on impressions, we will need facts | 13:38 |
| pave1 | Not sure. I don't have experience with that part. | 13:38 |
| patersonc | jki: Sure | 13:39 |
| pave1 | jki: I guess we should take someone experienced in security to do the analysis, so that it can't be easily brushed out with 'but Greg believes otherwise'. | 13:39 |
| jki | folks, I'm getting an urgent call - give me 5 min. | 13:40 |
| pave1 | jki: This is going to be huge problem for the security team in the long run... | 13:40 |
| pave1 | (or with "but it is better to err on side of caution"). | 13:42 |
| jki | back | 13:45 |
| jki | yes, I'm still scouting for comments internally, but also those folks will need more datapoints than what we have after only 3 weeks | 13:46 |
| pave1 | Ok. So should I spend say 10 hours | 13:47 |
| pave1 | trying to randomly pick some "new" CVEs and analyze them? | 13:47 |
| jki | yes, I think we should invest this (after the next pending -rt release ;-) ) | 13:48 |
| pave1 | Or would it be more valuable to pick the "worst" CVEs? | 13:48 |
| jki | the more data, the better | 13:48 |
| pave1 | Ok ;-). | 13:48 |
| jki | bad examples help, but their share in the overall number as well | 13:48 |
| jki | ok, clock is ticking for today - should we move on? | 13:49 |
| jki | 5 | 13:49 |
| jki | 4 | 13:49 |
| jki | 3 | 13:49 |
| jki | 2 | 13:49 |
| jki | 1 | 13:50 |
| jki | #topic Kernel release status | 13:50 |
| *** collab-meetbot` changes topic to "Kernel release status (Meeting topic: CIP IRC weekly meeting)" | 13:50 | |
| jki | 4.4-rt is late, rest on time | 13:50 |
| pave1 | I need to do 4.4-rt. | 13:50 |
| jki | any blockers? | 13:50 |
| pave1 | Not really. I was waiting for 4.4.x. | 13:50 |
| jki | good | 13:50 |
| jki | then move on | 13:50 |
| jki | #topic Kernel testing | 13:50 |
| *** collab-meetbot` changes topic to "Kernel testing (Meeting topic: CIP IRC weekly meeting)" | 13:50 | |
| arisut | still investigating in the kernelci core api but not updates yet | 13:51 |
| pave1 | 6.8 is out. Would be good to start testing 6.8-stable. | 13:51 |
| arisut | kernelci is also in a bit of a change phase | 13:52 |
| patersonc | pave1: I'll set it up when the first -rc is out (it wasn't when I last checked) | 13:52 |
| pave1 | -rc1 is now out. | 13:52 |
| patersonc | pave1: Okay | 13:52 |
| pave1 | Thank you! | 13:53 |
| patersonc | In the last "test report" email I sent I linked to Sietze's work on test reporting, did anyone see it? | 13:54 |
| patersonc | https://cip-playground.gitlab.io/squad-hacking/cip-release-reports/ | 13:54 |
| patersonc | Each build done gets a pretty/easy html page with a summary | 13:54 |
| patersonc | Still WIP, but a good starting point | 13:54 |
| patersonc | e.g. https://cip-playground.gitlab.io/squad-hacking/cip-release-reports/linux-cip/linux-4.19.y-cip/4.19.306-cip107_800dfc28d.html | 13:55 |
| pave1 | We currently have "There are failed tests" and "there are no failed tests". | 13:55 |
| pave1 | More different messages would be now. | 13:55 |
| pave1 | be nice. | 13:56 |
| pave1 | And 4.19 is failing a lot -- is that expected? https://cip-playground.gitlab.io/squad-hacking/cip-release-reports/linux-cip/linux-4.19.y-cip/4.19.309-cip107_bae57856d.html | 13:56 |
| patersonc | Do the red cross and green tick not help? | 13:56 |
| patersonc | There are lots of errors for LTP, always have been. We still need to work if they are meant to be failing or not. At least with squad we can now work out if there are any changes in the lists | 13:57 |
| pave1 | Dunno. Negative sentences can be confusing. Green tick makes it better. | 13:58 |
| pave1 | "All ok" would be even better :-). | 13:58 |
| patersonc | Please add feedback to the gitlab issue: https://gitlab.com/cip-project/cip-testing/testing/-/issues/211 | 13:58 |
| pave1 | And "incomplete tests" is something for you to investigate, too? | 13:59 |
| patersonc | Sure | 14:00 |
| jki | okay - need to leave soon - more testing topics? | 14:01 |
| jki | 5 | 14:02 |
| jki | 4 | 14:02 |
| jki | 3 | 14:02 |
| jki | 2 | 14:02 |
| jki | 1 | 14:02 |
| jki | #topic AOB | 14:02 |
| *** collab-meetbot` changes topic to "AOB (Meeting topic: CIP IRC weekly meeting)" | 14:02 | |
| pave1 | 6.1.81 was kind of strange, having series of nfs and x86 changes. | 14:03 |
| pave1 | It looks like this was due to CVEs... and it seems we have another x86 CPU bug. | 14:03 |
| pave1 | This time it effects Atom, so it may be more relevant to us. | 14:03 |
| pave1 | I've seen Intel information, still if someone had better explanation what is going on there, it would be nice. | 14:04 |
| jki | yeah, another HW vul | 14:04 |
| jki | register content leakage on context switch, but I didn't look into all details | 14:04 |
| jki | but it can become an interesting topic if the mitigation is hard to backport | 14:04 |
| pave1 | Yes, they seem to have some kind of "quick store forwarding" circuit, or something. | 14:04 |
| jki | we will need to check correlation of affected cores, their age, and CIP kernel usage for them (to the degree that's guessable) | 14:05 |
| pave1 | -stable has backports of the fix for 6.1, but not 5.10 | 14:06 |
| gregkh | Greg is not spamming anything, he is doing exactly what the cve board told him to do, pave1 please stop spraying lies | 14:06 |
| pave1 | Oh, welcome. | 14:06 |
| pave1 | gregkh: Obviously I don't know what they told you, but the end result looks suspiciously like a spam. | 14:07 |
| gregkh | I've always been here :) | 14:07 |
| pave1 | gregkh: So... how long have you been analysing CVE-2021-47050 ? | 14:07 |
| gregkh | pave1: if you are upset at what we are required to do, please take it up with the cve group, as we are doing what they required us to do | 14:08 |
| pave1 | gregkh: Are you required to submit non-bugs as a CVEs? | 14:08 |
| pave1 | gregkh: how long have you been analysing CVE-2021-47050 ? | 14:08 |
| gregkh | That came from the gsd import into cave, still ongoing will take a few months | 14:09 |
| gregkh | *cve, autocorrect... | 14:09 |
| gregkh | Anyway again if people have questions email us please | 14:09 |
| pave1 | gregkh: Yes, and it has your name on it, so I assume you have analysed it. Did you? | 14:10 |
| gregkh | I must have, along with others, but I'm on vacation now, and can't remember specifics, if you have questions, again, email | 14:12 |
| patersonc | Thanks Greg | 14:13 |
| jki | good that we are talking :) | 14:13 |
| jki | thanks! | 14:13 |
| pave1 | gregkh: I don't have questions. I'm complaining about changelogs being copy pasted into CVEs without analysis. I believe "spam" is quite suitable word for that. | 14:13 |
| gregkh | And in reading that record, looks real to me, if anyone doesnt think so, again, email | 14:13 |
| gregkh | We take the log message directly, that's how we create cves | 14:14 |
| gregkh | That's how we do for all kernel CVe records | 14:14 |
| pave1 | gregkh: Yes, and that's a part of the problem. Because CVEs created that way don't make sense. | 14:14 |
| pave1 | In the Linux kernel, the following vulnerability has been resolved: | 14:15 |
| pave1 | memory: renesas-rpc-if: fix possible NULL pointer dereference of resource | 14:15 |
| pave1 | Vulnerability would be "Malicious dts could lead to system crash". | 14:16 |
| pave1 | Patch title is not vulnerability description. | 14:16 |
| jki | folks, don't need to stop discussions, but I would close the irc call for this week now | 14:18 |
| pave1 | Yep, lets do that. | 14:18 |
| jki | maybe best to actually use email for this particular CVE and discuss that way further | 14:18 |
| jki | #endmeeting | 14:19 |
| collab-meetbot` | Meeting ended Thu Mar 14 14:19:00 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:19 |
| collab-meetbot` | Minutes: http://ircbot.wl.linuxfoundation.org/meetings/cip/2024/03/cip.2024-03-14-13.04.html | 14:19 |
| collab-meetbot` | Minutes (text): http://ircbot.wl.linuxfoundation.org/meetings/cip/2024/03/cip.2024-03-14-13.04.txt | 14:19 |
| collab-meetbot` | Log: http://ircbot.wl.linuxfoundation.org/meetings/cip/2024/03/cip.2024-03-14-13.04.log.html | 14:19 |
| *** collab-meetbot` changes topic to "Civil Infrastructure Platform Project. CIP mailing list at https://lists.cip-project.org/g/cip-dev | CIP kernel meeting every Thursday at 13:00 UTC | Find the meeting logs at https://ircbot.wl.linuxfoundation.org/meetings/cip/ and chat logs at https://ircbot.wl.linuxfoundation.org/logs/%23cip/" | 14:19 | |
| jki | thanks all! | 14:19 |
| iwamatsu__ | thank you | 14:19 |
| uli | thanks | 14:19 |
| masami | thank you | 14:19 |
| pave1 | jki: Thank you. | 14:19 |
| arisut | thanks | 14:19 |
| *** masami <masami!~masami@FL1-219-107-72-235.tky.mesh.ad.jp> has quit IRC (Quit: Leaving) | 14:19 | |
| arisut | thanks gregkh :) | 14:19 |
| arisut | have a nice vacation ! | 14:20 |
| pave1 | jki: I don't see how taking this out to email is going to help anything... Creating new CVEs is clearly easier than taking them down :-(. | 14:21 |
| jki | pavel: complain once you tried and failed, don't do that based on "I will fail" | 14:22 |
| pave1 | jki: I don't expect to "fail". I'm pretty sure bad CVEs can be taken down with enough effort. But it feels wrong to invest hour into taking down CVE someone created in a minute. | 14:25 |
| jki | do it one, twice, maybe three times at most, then extrapolate | 14:25 |
| pave1 | jki: Ok, I can do that. Still would prefer someone from security team to do this, as presumably they have experience how CVEs are expected to look and how CNA is expected to behave. | 14:27 |
| jki | it takes both: process knowlegde and expertise in analysing the actual issues - that makes it hard | 14:31 |
| pave1 | jki: I'm willing to do the technical analysis, but like the help with the process knowledge. Anyway, let's take down three CVEs and see how it goes. | 14:32 |
| jki | pavel: TIA! | 14:32 |
| *** jki <jki!~jki@62.156.206.8> has quit IRC (Quit: Leaving) | 14:32 | |
| pave1 | jki :-). | 14:33 |
| *** iwamatsu__ <iwamatsu__!~iwamatsu_@2405:6581:5360:1800:7a44:f1a9:81f2:2da2> has quit IRC (Quit: Client closed) | 15:13 | |
| *** fbezdeka <fbezdeka!~flo@2a02:810d:8780:7fc:714b:7d2b:a26b:4d1a> has left #cip | 16:06 | |
| *** gregkh_ <gregkh_!sid42031@id-42031.ilkley.irccloud.com> has joined #cip | 18:10 | |
| *** gregkh <gregkh!sid42031@id-42031.ilkley.irccloud.com> has quit IRC (Ping timeout: 264 seconds) | 18:12 | |
| *** gregkh_ is now known as gregkh | 18:12 | |
| *** frieder <frieder!~frieder@40-179-142-46.pool.kielnet.net> has quit IRC (Remote host closed the connection) | 21:46 | |
| *** rajm <rajm!~robert@82.27.50.32> has quit IRC (Ping timeout: 272 seconds) | 22:45 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!