March 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1207900] Thinkpad P16 Gen 1 freezes when put into Dockingstation
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207900 https://bugzilla.suse.com/show_bug.cgi?id=1207900#c12 --- Comment #12 from Michael Vetter <mvetter(a)suse.com> --- I updated today, and with kernel 6.2.2 this notebook doesn't boot at all anymore. A light on the caps lock key is blinking. I booted the previous btrfs snapshot now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c10 --- Comment #10 from Martti Laaksonen <martti.laaksonen(a)sci.fi> --- Tested with kernel-default-6.2.6-1.1.gfa1a4c6 from Kernel:stable repo. Seems to work ok without amd_iommu=off kernel parameter. However, with 6.2.6 kernel I did notice this error(?) in the kernel boot messages: [ 9.413585] bender kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 9.413642] bender kernel: amdgpu: sdma_bitmap: 3 [ 9.443769] bender kernel: memmap_init_zone_device initialised 524288 pages in 4ms [ 9.443784] bender kernel: amdgpu: HMM registered 2048MB device memory [ 9.443872] bender kernel: kfd kfd: amdgpu: Failed to resume IOMMU for device 1002:15d8 [ 9.444071] bender kernel: kfd kfd: amdgpu: device 1002:15d8 NOT added due to errors With 6.1.12 kernel that error is not present: [ 8.604973] bender kernel: kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 8.605032] bender kernel: amdgpu: sdma_bitmap: 3 [ 8.632249] bender kernel: memmap_init_zone_device initialised 524288 pages in 4ms [ 8.632266] bender kernel: amdgpu: HMM registered 2048MB device memory [ 8.632419] bender kernel: amdgpu: Topology: Add APU node [0x15d8:0x1002] [ 8.632425] bender kernel: kfd kfd: amdgpu: added device 1002:15d8 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c32 --- Comment #32 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Joey Lee from comment #30) > I agree that the upstream solution is complex, and I do not fully understood > the Imputed or Transitive concept in their theory. But I think that those > certificates in db/mok must be differentiated based on functionality > purpose. The trust is not spread from a purpose to other purposes. I agree. Especially the distinction between CA keys and code-signing keys and other "low-level" purposes makes sense (although AFAIK the main reason for making the distinction is that it allows the certificates lower in the chain to be invalidated while the CA remains intact). But I still hold that it the db certificates aren't trusted, you can't trust anything in the system. A malware-infected firmware could have injected false certs, keys, and checksums into the kernel before it even starts. Intel TXT had that concept of a "dynamic root of trust", but TXT wasn't successful, so we're left with the static root of trust, which is the UEFI db, like it or not. Or am I missing something? Do modern TPMs provide us with a way to create a trust relationship which doesn't depend on trusting the firmware? > Using usage extension in certificates to separate different purposes is a > strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and > keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign > extend key usage. That makes sense. But it does not make sense to me that only the CA certs can be loaded into the machine keyring. Normally you provide the full chain of certificates that's necessary to verify any given signature. And the full chain in our case would comprise the code-signing certs as well. > I have applied Eric Snowberg's patch set on v6.2 kernel and tested. I used > the following kernel config, and I got a kernel behavior that is similar > with our downstream patch for modsign: > > ... > > For kernel module sign: > No difference with our downstream patch, all MOKs be add to .machine keyring > and link to .secondary_trusted_keys. So all MOKs can be used to verify > kernel modules. > > For .ima/.evm > All MOKs can be used to verify keys that will go to .ima/.evm keyrings. That sounds good. So we could actually use this setup, at least as long as upstream doesn't enforce CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y. That said, I still fail to understand what MokListTrustedRT is good for. And if we "enable it by default", we might as well just shred it, no? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c31 --- Comment #31 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #30) > I agree that the upstream solution is complex, and I do not fully understood > the Imputed or Transitive concept in their theory. But I think that those > certificates in db/mok must be differentiated based on functionality > purpose. The trust is not spread from a purpose to other purposes. And the x509 has purpose flags but the kernel trashes all of them except the CA flag. If it wants to differentiate purposes it needs to store those purpose flags. > > Using usage extension in certificates to separate different purposes is a > strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and > keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign > extend key usage. Which applies to both kexec and module loading, these are both code. Loaded into the same security context even. Yet kernel upstream inexplicably insists on using different keys for these making their scheme unusable for us. If it wants to differentiate kexec and module loading, or modules by different vendors it needs to invent new extension for that. Until such certificate extension exists both kernel and modules are code. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c9 --- Comment #9 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Jiri Slaby from comment #8) > I believe this is: > https://bugzilla.kernel.org/show_bug.cgi?id=216865 > > And it was fixed already. Namely in 6.2.3. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208938] Boot fails with kernel 6.2.1-1-default
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208938 https://bugzilla.suse.com/show_bug.cgi?id=1208938#c8 --- Comment #8 from Jiri Slaby <jslaby(a)suse.com> --- I believe this is: https://bugzilla.kernel.org/show_bug.cgi?id=216865 And it was fixed already. Could you guys retry with the latest kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209221 https://bugzilla.suse.com/show_bug.cgi?id=1209221#c4 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com, | |v.hilgert(a)gmx.net Flags| |needinfo?(v.hilgert(a)gmx.net | |) --- Comment #4 from Takashi Iwai <tiwai(a)suse.com> --- Is Leap 15.x installed on the system? If yes, could you try to install the old Leap 15.4 GM kernel and check whether the behavior is seen? That is, download Leap 15.4 kernel-default, kernel-default-extra and kernel-default-optional packages from http://download.opensuse.org/distribution/leap/15.4/repo/oss/x86_64/ and install them with zypper install --oldpackage option, boot with it and retest. In anyway, please give the hwinfo output. Also the dmesg outputs containing the errors you mentioned. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209221 http://bugzilla.opensuse.org/show_bug.cgi?id=1209221#c3 --- Comment #3 from Andreas Stieger <Andreas.Stieger(a)gmx.de> --- HP have weird behavior on low remaining battery capacity (not the current charge, but detected unreliability). So could be a power management or storage driver/controller issue -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208071] SELinux: restricting kernel_t causes issues for the way we setup Micro
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1208071 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs(a)opensuse.org |jsegitz(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209221] Leap 15.4, Leap 15.5 and Tumbleweed are not working without attached power supply
by bugzilla_noreply＠suse.com 14 Mar '23

14 Mar '23

1 0