20:00:30 #startmeeting 20:00:30 Meeting started Wed Oct 30 20:00:30 2024 UTC. The chair is waldi. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:38 #chair bwh carnil 20:00:38 Current chairs: bwh carnil waldi 20:00:44 Hi 20:00:45 hello! 20:00:45 welcome to todays meeting 20:01:51 #topic CVE in firmware-nonfree in stable 20:01:59 carnil: you wanted to discuss this? 20:02:19 yes, so let me summarize what the issue is 20:03:09 We have abatch of CVEs which got allocated in Intel advisories, in which we get to know in which upstream version YYYYMMDD some CVEs get fixed, so we can easily track when fixes go into unstable. But now the question is how we want to handle those in context of stable. 20:03:41 My feeling is that handling firmware-nonfree in lower suites then get risky to break things, and we in most cases do not even know wich exact firmware change is fixing a CVE 20:03:49 This is also something the LTS team is trying to deal with, and the results have not been pretty 20:04:19 For microcode updates the situation is easier as we can backport a version to the other suites by almost rebuilding the package, but that cannot work for firmware-nonfree as sometimes blobs get dropped 20:04:21 I agree that we usually lack specific information about which version of which file fixed the CVE 20:05:08 For LTS we also have a need to backport firmware to support newer kernel versions, which complicates this further 20:05:08 how do other distributions handle that? 20:05:23 so my proposal was to do nothing and ignore the CVEs for older releases, unless we get to know something has really a major impact, but this was the point we could discuss as I know we might have different views depending on which team looks at the issues 20:05:40 (this is my summary and question to the topic) 20:06:57 If we know roughly which files are involved, do you think it's worth askingwhoever submits updates to those files in linux-firmware? 20:07:12 Or has that already been tried? 20:08:43 bwh: I think I did in a handful cases tried to approach people upstream and got no answer from the Intel people, I was more lucky on questions on the Bluetooth stack, but not on firmware files 20:08:48 but I might just have been unlucky 20:08:54 OK 20:09:03 do i get this right. intel submits updates to linux-firmware and later assigns CVE and just lists the version in the advisory for them? 20:09:43 for the qustion from waldi, I think mostly we can say it is handled inconsistently as well in other distros. For instance for CVE-2022-40964 RedHat seems to have released updates, ubuntu still has "needs evaluation" and SUSE does not track it at all 20:10:22 waldi: mostly correct yes, see for instance https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00766.html wher it only says: 20:10:28 Intel® PROSet/Wireless WiFi drivers to mitigate this vulnerability will be up streamed by August 08, 2023. Consult the regular open-source channels to obtain this update. 20:11:42 so we have to go back to linux-firmware/20230804 as the upstream version containing all the fixes claimed 20:11:44 For Intel specifically I guess we have security contacts there that might be able to give more detail 20:14:51 bwh: so you suggest we should try to get https://security-tracker.debian.org/tracker/source-package/firmware-nonfree Intel answering which commits are relevant and then for a potential update just cherry-pick those which adds blobs, beeing careful to not remove any firmware? (almost all assigned CVEs are ever Intel related I think) 20:15:16 yes 20:16:06 I have to agree that we shouldn't upgrade the whole package for a security issue 20:16:38 (We probably still need to do that in LTS when updating the kernel, but at least that would be a comparatively rare event) 20:18:16 okay. so we ignore CVE by default and try to get more information from the vendor, usualy just Intel 20:19:05 ok I can agree that we should give it another few tries to make it possible to identify then the specific commits, and if so then make targeted updates. And agreeing not to update the whole package to a newer version in stable, oldstable and maybe older. 20:19:22 to me it sounds good, as well additionally with ignoring them for a start by default, pending further information from Intel 20:19:47 #agreed we should give it another few tries to make it possible to identify then the specific commits, and if so then make targeted updates 20:19:49 but we would need to make this clear as well to LTS contributin folks why we took this decision for the upper suites, so we can handle it consistently across the various teams down to LTS team 20:19:54 #agreed not to update the whole package to a newer version in stable, oldstable and maybe older 20:20:18 thanks a lot for the short discussion of it, was valuable and helpful! 20:21:33 #topic #1086229 - linux-image-6.1.0-26-amd64: System don't boot the GUI 20:24:15 I started to handle it, there are OOT, but with the attached lspci output, it might be the NIC drivers. It would be helpful to understand why GUI does not come up. What I did as well was looking on the regressions list if I find something related (but failed) 20:24:16 I guess we need to ask for /proc/modules? 20:24:50 to find out what the proprietary driver is 20:25:07 and the provided log does not show anything about taints, so this either from an unrelated system or missing all those stuff 20:25:30 yes, or a kernel log from the working system 20:25:38 right, that too 20:26:15 and also now idea what he means with "doesn't boot GUI" 20:26:47 I would assume gdm/kdm/whatever doesn't start 20:26:52 but this is a nvidia-system: "VGA compatible controller [0300]: NVIDIA Corporation GK208B" 20:26:53 but it's worth asking 20:27:25 yes but apparently working with nouveau 20:27:57 unless that's from the broken state, and the actual problem is it needs nvidia which didn't get built for the new version 20:28:44 which I was hoping this is the case, thus asked which dkms packages are installed (this though does not exclude it might have been installed around the package managment) 20:28:45 as the kernel log was from this state, it is likely the lspci output is as well 20:29:28 does nvidia stuff still works by replacing GL libs, which are then not longer compatible with anything else? 20:30:01 carnil: So I think the information to ask for would be (1) log from working version (2) /proc/modules from working version (3) lspci from working version 20:30:53 ok! 20:31:53 #action carnil to ask for more information 20:32:25 #topic #1085949 - Installer regression on ppc64el under PowerKVM 20:32:55 This is the bug report that I split off last week. No new information there 20:33:23 okay 20:34:07 #topic #1086230 - linux: LTFS mount failure on ATTO H680 due to possible pm80xx driver SCSI length mismatch 20:34:49 What even is LTFS? 20:35:31 no idea 20:35:39 https://en.wikipedia.org/wiki/Linear_Tape_File_System 20:35:45 bwh: I noticed intially ot got reported here: https://github.com/LinearTapeFileSystem/ltfs/issues/484 20:35:59 so asked to actually ask upstream 20:36:13 Right, and you noted this wasn't even reported on a Debian kernel 20:36:16 (upstream, maintainers of the pm80xx driver) 20:36:56 So I think we should close this 20:37:48 ok 20:37:51 yes 20:37:58 (-pve seems to be a Proxmox kernel that is based on *Ubuntu* kernel sources) 20:38:02 fwiw, he posted the question upstream, but I do not see/find it in the lore archives 20:39:50 but it's fine to close, I do not see we can make any action *unless* it's found to be an upstream issue and has to go back to 6.1.y 20:40:35 can you handle that? 20:40:47 yes ok! 20:41:03 #action carnil to close the bug 20:41:08 thx 20:41:40 #topic #1086175 - linux-image-6.1.0-26-amd64: panic at shutdown with rootfs on RAID1 while initialy resyncing 20:43:17 From the information give, it sounds like it ought to be easy to reproduce, and is fixed upstream 20:43:50 I can take some time to try to do that 20:44:15 #action bwh try to reproduce and see if fixed upstream 20:44:17 thx 20:45:33 anything else? 20:46:21 I guess not fo today. We still need to followup with a 6.12-rcX upload to experimental and try to review the new config options, features, etc ... 20:46:28 right 20:46:51 I see there was an update on #1076372 20:46:55 but we still have a bit of time until we have to move it to unstable (it = 6.12.y) and then continue updateing it for making it ready for trixie 20:47:22 bwh: I closed as agreed in the last meeting, and shortly after Stephan followed up with: 20:47:43 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076372#71 20:48:34 From that information it seems like there might be 2 different bugs 20:49:13 one affecting the Lexar SSD on 6.10+, the other affecting the Kingston SSD on 6.1 20:49:32 s/6.10/6.5/ 20:50:27 I don't know what to do next 20:51:04 would it be an option: 20:51:20 ask if able to reporduce any of those with the respective upstream versions 20:51:41 6.1.114 for the 6.1.y affecting one, and ask to test for the second 6.11.5, mainline and 20:52:14 then report the issues on the upstream lists (though which subsystems and lists?) 20:53:31 yes 20:53:59 Since we don't patch nvme, I'm not sure we even need to ask to test upstream first, but I suppose it will be preparation for testing candidates fixes from upstream 20:55:01 ok I guess we have a next action for that 20:55:51 #topic aob 20:55:57 if nobody feels I'm getting to be the bottleneck, then I take it as acktion to ask and report it then to the nvme subsystem maintainers 20:56:07 s/acktion/action/ 20:56:17 #action carnil to work on #1076372 20:56:26 anything else? 20:56:39 Nothing from me 20:56:46 nothing from me 20:56:47 who wants to chair next week? 20:57:30 It's my turn 20:57:39 #action bwh to chair the next meeting 20:57:49 thank you for joining everyone 20:57:53 #endmeeting