July 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173944] Kernel 5.3.18-lp152.20.7 doesn't load VirtualBox kernel driver
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173944 https://bugzilla.suse.com/show_bug.cgi?id=1173944#c9 --- Comment #9 from Chris Taylor <chris.taylor(a)cantab.net> --- So is there a workaround or other solution so I can reenable secure boot? And could this happen again? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c61 --- Comment #61 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Joey Lee from comment #59) > Yes, I think this is the key point. User should enroll the nolockdown kernel > key by them self because shim will not embeds this "nolockdown kernel key". That's not a big problem. The situation would be the same as we have today with TW and Leap 15.1. The deployment of the new key via mokutil is pretty streamlined and yet safe. > Microsoft will not sign that shim. The shim shipped by openSUSE *is* signed by Microsoft, despite the fact that no openSUSE kernel released in the last few years had the lockdown feature. Or am I getting that wrong? (In reply to Michal Kubeček from comment #60) > But even if we could afford it, I'm still not convinced we should because the > way I see it, such change would make secure boot essentially useless. You're probably aware that opinions on this subject differ strongly, even among the experts. While I tend to agree in principle, please let's realize that until a few days ago, no Leap 15 kernel was enforcing signed modules. We might all have our secure boot chain subverted years ago, and never noticed. IOW, secure boot has always been "useless" on Leap. openSUSE can only improve in this area. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173944] Kernel 5.3.18-lp152.20.7 doesn't load VirtualBox kernel driver
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173944 https://bugzilla.suse.com/show_bug.cgi?id=1173944#c8 --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- That's my understanding, too. By some reason, a different key was used for the update project. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c60 --- Comment #60 from Michal Kubeček <mkubecek(a)suse.com> --- (In reply to Joey Lee from comment #59) > Yes, I think this is the key point. User should enroll the nolockdown kernel > key by them self because shim will not embeds this "nolockdown kernel key". > Microsoft will not sign that shim. That's a relevant point. Just to be sure I understand: we would have exactly the same problem if we disabled LOCK_DOWN_IN_EFI_SECURE_BOOT in Leap 15.2 kernel-default and kernel-preempt, wouldn't we? Also, I didn't check the code but would LOCK_DOWN_IN_EFI_SECURE_BOOT affect kABI? But even if we could afford it, I'm still not convinced we should because the way I see it, such change would make secure boot essentially useless. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173944] Kernel 5.3.18-lp152.20.7 doesn't load VirtualBox kernel driver
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173944 https://bugzilla.suse.com/show_bug.cgi?id=1173944#c7 --- Comment #7 from Michal Kubeček <mkubecek(a)suse.com> --- (In reply to Takashi Iwai from comment #6) > Indeed they seem to have been built with different keys. > > % rpm -ql kernel-default-5.3.18-lp152.19.2.x86_64 | grep /etc/uefi/certs/ > /etc/uefi/certs/F1C08E27.crt > > % rpm -ql kernel-default-5.3.18-lp152.20.7.1.x86_64 | grep /etc/uefi/certs/ > /etc/uefi/certs/188EA6FA.crt IIRC lp152.19 was the GM kernel and lp152.20 is the first maintenance update (I would have to check commit ids to be sure). Could this be the reason why is each signed by a different key? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c59 --- Comment #59 from Joey Lee <jlee(a)suse.com> --- (In reply to Martin Wilck from comment #45) > While I think the KMP solution is The Right Thing (TM), it is obviously not > viable short-term. Here's an idea what we can do quickly: > > - create a new kernel flavor, call it "nolockdown" or whatever, that > loosens lockdown features enough to load NVidia and other proprietary > drivers. > - sign this flavor with a different key, which is not allowed on SB systems > by default. People who want to use that key would need to set it up using > mokutil. that would be a one-time measure, as opposed to having to provide > keys with every driver rebuild. Yes, I think this is the key point. User should enroll the nolockdown kernel key by them self because shim will not embeds this "nolockdown kernel key". Microsoft will not sign that shim. > - that kernel package could be accompanied by an EULA file explaining why > it exists and what the security implications are. > > Advantages: > > * It allows leaving the secure boot setting on in the BIOS (might be > mandated by another OS on the system, or other policies). > * It satisfies the security requirement that enabling it requires an > explicit action of the user in the UEFI environment ("physical presence" - > well). > * It's far better than adding a "nolockdown" kernel command line parameter > from a security PoV. > * Security-wise, people using this kernel would be as "good" as Leap 15.1 > users, possibly a little better off. > * It's less hassle for users than having to create and deploy keys > themselved, possibly repeatedly. > * It should be pretty quick to implement, no re-engineering of NVidia > drivers needed. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173158] CONFIG_MODULE_SIG=y
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173158 https://bugzilla.suse.com/show_bug.cgi?id=1173158#c58 --- Comment #58 from Joey Lee <jlee(a)suse.com> --- (In reply to Joey Lee from comment #57) [...snip] > > The SUSE patch be applied on old SLE kernel. For any new kernel after > v5.2-rc1, Mimi Zohar's IMA patch puts the same logic to mainline kernel: > > commit 8db5da0b8618df79eceea99672e205d4a2a6309e > Author: Mimi Zohar <zohar(a)linux.ibm.com> > Date: Sun Jan 27 19:03:45 2019 -0500 > > x86/ima: require signed kernel modules [...snip] > > But the logic only works with CONFIG_IMA_ARCH_POLICY=y. We didn't enable it > on SLE/openSUSE. Which means that the SIG_FORCE should not be enabled when > secure boot on SLE15-SP2 or LEAP 15.2. > > On SLE15-SP2, the integrity lock-down mode be enabled when secure boot > enabled. It only enable MODULE_SIG but I didn't see MODULE_SIG_FORCE. > > I will use qemu-OVMF to look at the behavior again. I just used the qemu-OVMF to confirm the behavior of MODULE_SIG_FORCE on SLE15-SP2: - When secure boot be disabled: A unsigned kernel module can be loaded but it will taint kernel. - When secure boot enabled. Unsigned kernel module can NOT be loaded, got permission deny. e.g. linux-npj3:~/tmp # insmod acer-wmi.ko insmod: ERROR: could not insert module acer-wmi.ko: Operation not permitted [ 73.282012] Lockdown: insmod: unsigned module loading is restricted; see man kernel_lockdown.7 After the lock-down patch set be merged to mainline. The logic of sig_force is more complicated because IMA involved. There have three ways to set the sig_force: - CONFIG_MODULE_SIG_FORCE=y Static kernel config for always deny unsigned module. SLE/Leap disabled CONFIG_MODULE_SIG_FORCE. - CONFIG_IMA_ARCH_POLICY=y + Secure_Boot_ON IMA architecture specific policy be set, and the secure boot be enabled. Then sig_force will be set. SLE/Leap disabled CONFIG_IMA_ARCH_POLICY. - When kernel is in Lock-down mode (INTEGRITY or CONFIDENTIALITY mode) SLE/Leap will lock-down on INTEGRITY mode when secure boot be enabled because we applied patch and set LOCK_DOWN_IN_EFI_SECURE_BOOT=y. When kernel is in lock-down mode, the sig_force will be set. For disabling sig_force, either we set LOCK_DOWN_IN_EFI_SECURE_BOOT=n in Leap kernel config. Or end user choice to disable secure boot in firmware. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173944] Kernel 5.3.18-lp152.20.7 doesn't load VirtualBox kernel driver
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173944 https://bugzilla.suse.com/show_bug.cgi?id=1173944#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com Flags| |needinfo?(chris.taylor@cant | |ab.net) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Please check whether weak link is created in /lib/modules/5.3.18-lp152.20.7-default/weak-updates/ from the installed KMPs. i.e. you must have some vbox modules in /lib/modules/5.3.18-lp152.19-default/updates/*, and those must have been symlinked to /lib/modules/weak-updates/*. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173860] New: kernel-5.3.18-lp152.20.7.1 crash at boot with permissions violation
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1173860 Bug ID: 1173860 Summary: kernel-5.3.18-lp152.20.7.1 crash at boot with permissions violation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: martin.tessun(a)die-tessuns.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After Updating to the new kernel (5.3.18-lp152.20.7.1) my system does no longer boot. The kernel "hangs" while flooding the console with page fault issues. kernel-5.3.18-lp152.19.2 works perfectly fine. As the issue happens in early stages, I do not have a dump or any logs - just some "tries" of reading the screen. System details: - UEFI - Secure Boot disabled - Manufacturer: ASRock - Product Name: J3455-ITX BIOS Information Vendor: American Megatrends Inc. Version: P1.60 Release Date: 01/16/2018 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 8192 kB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 5.12 Unfortunately the system is completely unresponsible so some fragments for the recurring kernel OOPS: Fixing recursive fault, but reboot is needed! BUG: Unable to handle page fault for address: 0x.... #PF: supervisot write access in kernel mode #PF: error_code(0x0003) - permissions violation Oops: 0003 [#8635] SMP NOPTI CPU 0 PID: 495 Comm: systemd-udevd Tainted: ... Hardware name: To be filled by O.E.M RIP: 0010:blk_flush_plug_list+0x6c/0xf0 Some dmesg from the working kernel (5.3.18-lp152.19.2): [ 0.000000] microcode: microcode updated early to revision 0x38, date = 2019-01-15 [ 0.000000] Linux version 5.3.18-lp152.19-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Tue Jun 9 20:59:24 UTC 2020 (960cb00) [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.3.18-lp152.19-default root=/dev/mapper/system-root splash=silent resume=/dev/mapper/system-swap quiet mitigations=auto [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [ 0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [ 0.000000] x86/fpu: xstate_offset[3]: 576, xstate_sizes[3]: 64 [ 0.000000] x86/fpu: xstate_offset[4]: 640, xstate_sizes[4]: 64 [ 0.000000] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format. [...] [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] e820: update [mem 0x643e2018-0x643f2057] usable ==> usable [ 0.000000] e820: update [mem 0x643e2018-0x643f2057] usable ==> usable [ 0.000000] e820: update [mem 0x643d3018-0x643e1057] usable ==> usable [ 0.000000] e820: update [mem 0x643d3018-0x643e1057] usable ==> usable [ 0.000000] extended physical RAM map: [...] [ 0.000000] efi: EFI v2.50 by American Megatrends [ 0.000000] efi: TPMFinalLog=0x6d9bd000 ESRT=0x6dd82918 ACPI=0x6d99e000 ACPI 2.0=0x6d99e000 SMBIOS=0x6dc4f000 SMBIOS 3.0=0x6dc4e000 TPMEventLog=0x643f3018 [ 0.000000] secureboot: Secure boot disabled [ 0.000000] SMBIOS 3.0.0 present. [ 0.000000] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./J3455-ITX, BIOS P1.60 01/16/2018 [ 0.000000] tsc: Detected 1497.600 MHz processor [ 0.000029] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved [ 0.000033] e820: remove [mem 0x000a0000-0x000fffff] usable [ 0.000050] last_pfn = 0x480000 max_arch_pfn = 0x400000000 [ 0.000056] MTRR default type: uncachable [ 0.000058] MTRR fixed ranges enabled: [ 0.000060] 00000-6FFFF write-back [ 0.000062] 70000-7FFFF uncachable [ 0.000064] 80000-9FFFF write-back [ 0.000065] A0000-BFFFF uncachable [ 0.000067] C0000-FFFFF write-protect [ 0.000069] MTRR variable ranges enabled: [...] [ 0.000179] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [ 0.000255] last_pfn = 0x6f000 max_arch_pfn = 0x400000000 [ 0.007627] esrt: Reserving ESRT space from 0x000000006dd82918 to 0x000000006dd82950. [ 0.007646] check: Scanning 1 areas for low memory corruption [ 0.007655] Using GB pages for direct mapping [ 0.007659] BRK [0x2fe001000, 0x2fe001fff] PGTABLE [ 0.007663] BRK [0x2fe002000, 0x2fe002fff] PGTABLE [ 0.007666] BRK [0x2fe003000, 0x2fe003fff] PGTABLE [ 0.007785] BRK [0x2fe004000, 0x2fe004fff] PGTABLE [ 0.008108] BRK [0x2fe005000, 0x2fe005fff] PGTABLE [ 0.008208] BRK [0x2fe006000, 0x2fe006fff] PGTABLE [ 0.008334] BRK [0x2fe007000, 0x2fe007fff] PGTABLE [ 0.008584] BRK [0x2fe008000, 0x2fe008fff] PGTABLE [ 0.008726] BRK [0x2fe009000, 0x2fe009fff] PGTABLE [ 0.008935] BRK [0x2fe00a000, 0x2fe00afff] PGTABLE [ 0.009292] BRK [0x2fe00b000, 0x2fe00bfff] PGTABLE [ 0.009716] secureboot: Secure boot disabled [ 0.009718] RAMDISK: [mem 0x3efc7000-0x3fffafff] [ 0.009734] ACPI: Early table checksum verification disabled [...] [ 0.010163] No NUMA configuration found [ 0.010165] Faking a node at [mem 0x0000000000000000-0x000000047fffffff] [ 0.010182] NODE_DATA(0) allocated [mem 0x47ffea000-0x47fffffff] [ 0.010286] Zone ranges: [ 0.010288] DMA [mem 0x0000000000001000-0x0000000000ffffff] [ 0.010291] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] [ 0.010293] Normal [mem 0x0000000100000000-0x000000047fffffff] [ 0.010295] Device empty [ 0.010297] Movable zone start for each node [ 0.010300] Early memory node ranges [...] [ 0.010816] Zeroed struct page in unavailable ranges: 22339 pages [ 0.010820] Initmem setup node 0 [mem 0x0000000000001000-0x000000047fffffff] [ 0.010824] On node 0 totalpages: 4106429 [ 0.010827] DMA zone: 64 pages used for memmap [ 0.010828] DMA zone: 21 pages reserved [ 0.010830] DMA zone: 3996 pages, LIFO batch:0 [ 0.011007] DMA32 zone: 6757 pages used for memmap [ 0.011008] DMA32 zone: 432417 pages, LIFO batch:63 [ 0.039794] Normal zone: 57344 pages used for memmap [ 0.039795] Normal zone: 3670016 pages, LIFO batch:63 [ 0.041225] Reserving Intel graphics memory at [mem 0x70000000-0x7fffffff] [ 0.041456] ACPI: PM-Timer IO Port: 0x408 [ 0.041460] ACPI: Local APIC address 0xfee00000 [ 0.041474] ACPI: LAPIC_NMI (acpi_id[0x01] high level lint[0x1]) [ 0.041476] ACPI: LAPIC_NMI (acpi_id[0x02] high level lint[0x1]) [ 0.041478] ACPI: LAPIC_NMI (acpi_id[0x03] high level lint[0x1]) [ 0.041479] ACPI: LAPIC_NMI (acpi_id[0x04] high level lint[0x1]) [ 0.041518] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-119 [ 0.041522] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.041525] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [ 0.041528] ACPI: IRQ0 used by override. [ 0.041530] ACPI: IRQ9 used by override. [ 0.041533] Using ACPI (MADT) for SMP configuration information [ 0.041536] ACPI: HPET id: 0x8086a701 base: 0xfed00000 [ 0.041558] smpboot: Allowing 4 CPUs, 0 hotplug CPUs [...] [ 0.041696] Booting paravirtualized kernel on bare hardware [ 0.041702] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns [ 0.300440] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:4 nr_node_ids:1 [ 0.301012] percpu: Embedded 56 pages/cpu s192512 r8192 d28672 u524288 [ 0.301031] pcpu-alloc: s192512 r8192 d28672 u524288 alloc=1*2097152 [ 0.301033] pcpu-alloc: [0] 0 1 2 3 [ 0.301096] Built 1 zonelists, mobility grouping on. Total pages: 4042243 [ 0.301098] Policy zone: Normal [ 0.301102] Kernel command line: BOOT_IMAGE=/vmlinuz-5.3.18-lp152.19-default root=/dev/mapper/system-root splash=silent resume=/dev/mapper/system-swap quiet mitigations=auto [...] [ 0.412628] Last level iTLB entries: 4KB 48, 2MB 0, 4MB 0 [ 0.412630] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 [ 0.412637] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization [ 0.412640] Spectre V2 : Mitigation: Full generic retpoline [ 0.412641] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch [ 0.412642] Spectre V2 : Enabling Restricted Speculation for firmware calls [ 0.412645] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier [ 0.413137] Freeing SMP alternatives memory: 36K [ 0.416087] TSC deadline timer enabled [ 0.416096] smpboot: CPU0: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz (family: 0x6, model: 0x5c, stepping: 0x9) [...] [ 0.417097] smp: Bringing up secondary CPUs ... [ 0.417097] x86: Booting SMP configuration: [ 0.417097] .... node #0, CPUs: #1 #2 #3 [ 0.417793] smp: Brought up 1 node, 4 CPUs [ 0.417793] smpboot: Max logical packages: 1 [ 0.417793] smpboot: Total of 4 processors activated (11980.80 BogoMIPS) [ 0.533128] node 0 initialised, 3555943 pages in 116ms [ 0.537100] devtmpfs: initialized [ 0.537239] x86/mm: Memory block size: 128MB [ 0.537808] PM: Registering ACPI NVS region [mem 0x6d99e000-0x6d9d4fff] (225280 bytes) [ 0.537808] PM: Registering ACPI NVS region [mem 0x6e155000-0x6e155fff] (4096 bytes) [ 0.537808] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.537808] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) [ 0.537808] pinctrl core: initialized pinctrl subsystem [ 0.537808] PM: RTC time: 17:35:41, date: 2020-07-07 [ 0.541102] NET: Registered protocol family 16 -- You are receiving this mail because: You are the assignee for the bug.

1 22

[kernel-bugs] [Bug 1173860] kernel-5.3.18-lp152.20.7.1 crash at boot with permissions violation
by bugzilla_noreply＠suse.com 09 Jul '20

09 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173860 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? -- You are receiving this mail because: You are the assignee for the bug.

1 0