[Kernel-packages] [Bug 1930733] Re: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI
> should it fail how can I get the log when my system completely locks up and dies? My understanding of the bug is that it occurs when the NVIDIA driver tries to bring up the DisplayPort link on certain DisplayPort monitors. You should be able to drive the system in text mode with a failing driver, to capture the log. One way to do that would be to add "systemd.unit=multi-user.target" to the kernel command line. (When the bootloader menu comes up, edit the boot options and add this argument to the line that starts with 'linux'.) If you happen to have another system on the same network you can even try SSHing into the system that reproduces the problem, then start the graphical session manually with `sudo systemctl isolate graphical`, and if the crash doesn't take down the SSH session, you ought to be able to generate the log file while the problem is occurring. (Log files taken while a bug is actively being reproduced tend to be the most useful.) Depending on the exact nature of the crash, you may even be able to SSH into a system which has already crashed, without having to go to the effort of starting it in text mode first. > In that eventuality I've only been able to recover by booting an older kernel with the older drivers. Will that not invalidate the log content on restart? It may, or may not. nvidia-bug-report.sh attempts to capture logs from the previous boot, if they have been retained. If you do find that you are unable to capture a log file using a driver version which reproduces the problem, just make sure to note that you captured the log file after rebooting to a known good driver. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-460 in Ubuntu. https://bugs.launchpad.net/bugs/1930733 Title: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI Status in nvidia-graphics-drivers-460 package in Ubuntu: Triaged Status in nvidia-graphics-drivers-465 package in Ubuntu: Triaged Bug description: I get a kernel oops with the 460.80 and 465.27 drivers on Hirsute Jun 03 16:26:57 willow kernel: Oops: [#1] SMP PTI Jun 03 16:26:57 willow kernel: CPU: 7 PID: 2004 Comm: Xorg Tainted: P OE 5.11.0-18-generic #19-Ubuntu Jun 03 16:26:57 willow kernel: Hardware name: System manufacturer System Product Name/PRIME H270M-PLUS, BIOS 1605 12/13/2019 Jun 03 16:26:57 willow kernel: RIP: 0010:_nv015534rm+0x1b6/0x330 [nvidia] Jun 03 16:26:57 willow kernel: Code: 8b 87 68 05 00 00 ba 01 00 00 00 be 02 00 00 00 e8 bf eb 55 c8 41 83 c5 01 41 83 fd 1f 0f 84 0b 01 00 00 48 8b 45 10 44 89 ee <48> 8b b8 70 01 00 00 48 8b 87 d8 04 00 00 e8> Jun 03 16:26:57 willow kernel: RSP: :af4201893958 EFLAGS: 00010297 Jun 03 16:26:57 willow kernel: RAX: RBX: 0400 RCX: 0003 Jun 03 16:26:57 willow kernel: RDX: 0004 RSI: 0003 RDI: Jun 03 16:26:57 willow kernel: RBP: 8e318220add0 R08: 0001 R09: 8e318220acb8 Jun 03 16:26:57 willow kernel: R10: 8e3182204008 R11: 1010 R12: 0400 Jun 03 16:26:57 willow kernel: R13: 0003 R14: 8e3186ca8010 R15: 0800 Jun 03 16:26:57 willow kernel: FS: 7f5807f38a40() GS:8e3466dc() knlGS: Jun 03 16:26:57 willow kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 03 16:26:57 willow kernel: CR2: 0170 CR3: 000140710005 CR4: 003706e0 Jun 03 16:26:57 willow kernel: DR0: DR1: DR2: Jun 03 16:26:57 willow kernel: DR3: DR6: fffe0ff0 DR7: 0400 Jun 03 16:26:57 willow kernel: Call Trace: Jun 03 16:26:57 willow kernel: ? _nv015556rm+0x7fd/0x1020 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv027155rm+0x22c/0x4f0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017787rm+0x303/0x5e0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017789rm+0xe1/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv022829rm+0xed/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv023065rm+0x30/0x60 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv000704rm+0x16da/0x22b0 [nvidia] Jun 03 16:26:57 willow kernel: ? rm_init_adapter+0xc5/0xe0 [nvidia] Jun 03 16:26:57 willow kernel: ? nv_open_device+0x122/0x8e0 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_open+0x2b7/0x560 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_frontend_open+0x58/0xa0 [nvidia] Jun 03 16:26:57 willow kernel: ? chrdev_open+0xf7/0x220 Jun 03 16:26:57 willow kernel: ? cdev_device_add+0x90/0x90 Jun 03 16:26:57 willow kernel: ? do_dentry_open+0x156/0x370 Jun 03 16:26:57 willow kernel: ? vfs_open+0x2d/0x30 Jun 03 16:26:57 willow kernel: ? do_open+0x1c3/0x340 Jun 03 16:26:57 willow kernel: ? path_openat+0x10a/0x1d0 Jun 03 16:26:57 willow kernel:
[Kernel-packages] [Bug 1930733] Re: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI
Hello, NVIDIA employee here. Can those who are still experiencing problems please provide the following information? * NVIDIA driver version installed * NVIDIA GPU model * Exact model of affected monitor An nvidia-bug-report.log will capture the driver version and GPU model, along with some other useful information, though possibly not the monitor model since the system may be crashing before the EDID can be read. You can generate an nvidia-bug-report.log file by running `nvidia- bug-report.sh` as root. This will create a new file named nvidia-bug- report.log.gz in your current directory. As for the fix being absent from the release notes, that was an accidental omission. The fix should be present in 460.91.03 and later, as well as all publicly released 470 drivers. Unfortunately, the fix did not make it into 465 before support for the 465 series was discontinued. We will want to collect the relevant information for anybody still experiencing problems with DP monitors so that any remaining issues can be addressed as well. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-460 in Ubuntu. https://bugs.launchpad.net/bugs/1930733 Title: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI Status in nvidia-graphics-drivers-460 package in Ubuntu: Triaged Status in nvidia-graphics-drivers-465 package in Ubuntu: Triaged Bug description: I get a kernel oops with the 460.80 and 465.27 drivers on Hirsute Jun 03 16:26:57 willow kernel: Oops: [#1] SMP PTI Jun 03 16:26:57 willow kernel: CPU: 7 PID: 2004 Comm: Xorg Tainted: P OE 5.11.0-18-generic #19-Ubuntu Jun 03 16:26:57 willow kernel: Hardware name: System manufacturer System Product Name/PRIME H270M-PLUS, BIOS 1605 12/13/2019 Jun 03 16:26:57 willow kernel: RIP: 0010:_nv015534rm+0x1b6/0x330 [nvidia] Jun 03 16:26:57 willow kernel: Code: 8b 87 68 05 00 00 ba 01 00 00 00 be 02 00 00 00 e8 bf eb 55 c8 41 83 c5 01 41 83 fd 1f 0f 84 0b 01 00 00 48 8b 45 10 44 89 ee <48> 8b b8 70 01 00 00 48 8b 87 d8 04 00 00 e8> Jun 03 16:26:57 willow kernel: RSP: :af4201893958 EFLAGS: 00010297 Jun 03 16:26:57 willow kernel: RAX: RBX: 0400 RCX: 0003 Jun 03 16:26:57 willow kernel: RDX: 0004 RSI: 0003 RDI: Jun 03 16:26:57 willow kernel: RBP: 8e318220add0 R08: 0001 R09: 8e318220acb8 Jun 03 16:26:57 willow kernel: R10: 8e3182204008 R11: 1010 R12: 0400 Jun 03 16:26:57 willow kernel: R13: 0003 R14: 8e3186ca8010 R15: 0800 Jun 03 16:26:57 willow kernel: FS: 7f5807f38a40() GS:8e3466dc() knlGS: Jun 03 16:26:57 willow kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 03 16:26:57 willow kernel: CR2: 0170 CR3: 000140710005 CR4: 003706e0 Jun 03 16:26:57 willow kernel: DR0: DR1: DR2: Jun 03 16:26:57 willow kernel: DR3: DR6: fffe0ff0 DR7: 0400 Jun 03 16:26:57 willow kernel: Call Trace: Jun 03 16:26:57 willow kernel: ? _nv015556rm+0x7fd/0x1020 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv027155rm+0x22c/0x4f0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017787rm+0x303/0x5e0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017789rm+0xe1/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv022829rm+0xed/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv023065rm+0x30/0x60 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv000704rm+0x16da/0x22b0 [nvidia] Jun 03 16:26:57 willow kernel: ? rm_init_adapter+0xc5/0xe0 [nvidia] Jun 03 16:26:57 willow kernel: ? nv_open_device+0x122/0x8e0 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_open+0x2b7/0x560 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_frontend_open+0x58/0xa0 [nvidia] Jun 03 16:26:57 willow kernel: ? chrdev_open+0xf7/0x220 Jun 03 16:26:57 willow kernel: ? cdev_device_add+0x90/0x90 Jun 03 16:26:57 willow kernel: ? do_dentry_open+0x156/0x370 Jun 03 16:26:57 willow kernel: ? vfs_open+0x2d/0x30 Jun 03 16:26:57 willow kernel: ? do_open+0x1c3/0x340 Jun 03 16:26:57 willow kernel: ? path_openat+0x10a/0x1d0 Jun 03 16:26:57 willow kernel: ? do_filp_open+0x8c/0x130 Jun 03 16:26:57 willow kernel: ? __check_object_size+0x1c/0x20 Jun 03 16:26:57 willow kernel: ? do_sys_openat2+0x9b/0x150 Jun 03 16:26:57 willow kernel: ? __x64_sys_openat+0x56/0x90 Jun 03 16:26:57 willow kernel: ? do_syscall_64+0x38/0x90 Jun 03 16:26:57 willow kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 03 16:26:57 willow kernel: Modules linked in: snd_seq_dummy snd_hrtimer vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) > Jun 03
[Kernel-packages] [Bug 1905591] Re: no brightness control in {455, 460} after update from 450
The workaround suggests that there's an interaction between the NVIDIA
driver and another kernel module at play here. Presumably, adding the
NVIDIA kernel modules to the initrd causes them to be loaded before the
other module. Maybe video.ko, which registers its own brightness
handler?
The modeswitch glitch should probably be tracked as a separate issue.
Can somebody who is experiencing this glitch provide an example video?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-455 in Ubuntu.
https://bugs.launchpad.net/bugs/1905591
Title:
no brightness control in {455,460} after update from 450
Status in OEM Priority Project:
New
Status in nvidia-graphics-drivers-455 package in Ubuntu:
Confirmed
Status in nvidia-graphics-drivers-460 package in Ubuntu:
Confirmed
Bug description:
On my Lenovo X1 Extreme with GPU: NVIDIA Corporation GP107M [GeForce
GTX 1050 Ti Mobile]:
WORKS FINE:
nvidia-driver-450: 450.102.04-0ubuntu0.18.04.1
NO BRIGHTNESS CONTROL:
nvidia-driver-455: 455.38-0ubuntu0.18.04.1
nvidia-driver-460: 460.32.03-0ubuntu0.18.04.1
nvidia-driver-460: 460.39-0ubuntu0.18.04.1
*WORKAROUND: See comment #11 (add nvidia drivers to initramfs).
*Note that 460 fixes it for a 20.04 ThinkPad P73 per comment #6, but
not for my 18.04.5 Lenovo ThinkPad X1 per comment #5.
Updating to nvidia-driver-455 (or -460) results in loss of brightness
control. On boot, the laptop display brightness is somewhat less than
fully bright and cannot be changed. The brightness up/down keys do
pop up the gnome gui brightness widget, and
/sys/class/backlight/nvidia_0/* values do change, but the actual
display's brightness does not.
Problem occurs with either version of nvidia-driver-455 (the archive
or the ~graphics-drivers/PPA) or any version of -460.
Normal functionality returns if I downgrade to any version of nvidia-
driver-450.
Also observed: 455 and 460 temporarily display some pixel garbage
while mode-switching during the graphic login sequence. Only a minor
glitch, but note that 450 does not exhibit that issue either.
Note also that manually applying this to
/lib/systemd/system/nvidia-persistenced.service has no effect on the problem:
https://github.com/hugh712/nvidia-graphics-drivers/commit/bccad5ee6444dd8c5c47ba19ea0232106a1086f5
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic
kernel: 5.4.0-54-generic #60~18.04.1-Ubuntu SMP Fri Nov 6 17:25:16 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1905591/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1905591] Re: no brightness control after update from 450 to 455
Can somebody with an affected system please try with one of the recently released 460.xx drivers? There were some brightness regressions that were resolved in the 460 series that may be related. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-455 in Ubuntu. https://bugs.launchpad.net/bugs/1905591 Title: no brightness control after update from 450 to 455 Status in OEM Priority Project: New Status in nvidia-graphics-drivers-455 package in Ubuntu: Triaged Bug description: On my Lenovo X1 Extreme with GPU: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Mobile] Updating to nvidia-driver-455 results in loss of brightness control. On boot, the laptop display brightness is somewhat less than fully bright and cannot be changed. The brightness up/down keys do pop up the gnome gui brightness widget, and /sys/class/backlight/nvidia_0/* values do change, but the actual display's brightness does not. Problem occurs with either version of nvidia-driver-455 (the archive or the ~graphics-drivers/PPA). Normal functionality returns if I downgrade to any version of nvidia-driver-450. Note also that manually applying this to /lib/systemd/system/nvidia-persistenced.service has no effect on the problem: https://github.com/hugh712/nvidia-graphics-drivers/commit/bccad5ee6444dd8c5c47ba19ea0232106a1086f5 Distributor ID: Ubuntu Description: Ubuntu 18.04.5 LTS Release: 18.04 Codename: bionic kernel: 5.4.0-54-generic #60~18.04.1-Ubuntu SMP Fri Nov 6 17:25:16 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux nvidia-driver-455: 455.38-0ubuntu0.18.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1905591/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1831945] Re: HDMI/DP audio: ELD not updated on hotplug event
Sorry, I didn't notice that this bug had expired, or that it was waiting on log files. I don't have the system that I originally reproduced the issue on set up any more, but it should be easily reproducible. I'll set up another system to reproduce and generate the requested log files, but in the meantime, I'm setting this to "Confirmed" anyway since this is really just a straightforward request to backport a change that fixes a kernel regression. ** Changed in: linux (Ubuntu) Status: Expired => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1831945 Title: HDMI/DP audio: ELD not updated on hotplug event Status in linux package in Ubuntu: Confirmed Bug description: When using HDMI or Displayport audio, the EDID-like Data (ELD) fails to update properly when hotplugging or hot-unplugging displays. This in turn prevents tools like the GNOME sound settings control panel from accurately presenting the system's current audio capabilities. How reproducible: Hot plug and hot unplug an audio-capable display and observe the state of the ELDs, either by directly reading the ELD files in /proc/asound/card*/eld* or by examining the available audio output devices in the GNOME sound settings control panel. Steps to Reproduce: 1. Log into a desktop session with no audio-capable displays plugged in 2. Plug in an audio-capable display 3. Open the GNOME sound settings control panel Actual results: The audio-capable display is not selectable as an output device. Expected results: The audio-capable display should be selectable as an output device. Additional info: This bug has been fixed upstream with commit 37a3a98ef601f89100e3bb657fb0e190b857028c. Applying this change alone to the bionic 4.18 HWE kernel is sufficient to allow the expected behavior to occur. It is likely to be sufficient to fix the same bug, assuming it exists, in Cosmic, but neither the presence of the bug nor the sufficiency of the patch were tested. The bug is likely not present in Disco, but this was not tested. This behavior was observed on a system with an NVIDIA GPU running the NVIDIA proprietary driver. The particular NVIDIA GPU on the system is not currently compatible with Nouveau. It is possible and likely that this problem is also reproducible on other systems which do have GPUs that are compatible with Nouveau, and even on systems with HDMI or Displayport connectors being driven by non-NVIDIA GPUs. When the ELD fails to update in response to a hotplug event, an update can be forced by accessing the underlying ALSA codec directly. For example, playing an audio stream directly via ALSA or even just reading from the /proc/asound/cardX/codec#Y file will cause the ELD to become updated. This is of course unnecessary if the patch which fixes the issue is applied, but it does offer a somewhat simple workaround for affected users until the patch can be backported. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831945/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1828084] Re: Kernel modules generated incorrectly when system is localized to a non-English language
amd64 counts as x86 for the purposes of supported architectures in Linux, and x86 does have the C version of recordmcount. Comment #3 includes a list of architectures that lack the C version of recordmcount. Of those architectures, ppc64le is the only one that is supported by the NVIDIA driver (the test case described in the reproduction steps). I did try to create a reproduction case independent of the NVIDIA driver, but was unsuccessful, as simpler kernel modules failed to cause a panic, and I hadn't isolated what specific behavior of the NVIDIA driver is problematic when recordmcount fails to run. One troubleshooting technique you can use to verify whether recordmcount.pl is working when localization options are set is to instrument the Kbuild makefiles to record a checksum of the object file recordmcount is run against before running recordmcount and again after it has run. If recordmcount fails to run the checksums will be the same. Note that this is only useful on architectures which use recordmcount.pl rather than the C version, as the C version has no dependency on parsing the output of objdump. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828084 Title: Kernel modules generated incorrectly when system is localized to a non-English language Status in linux package in Ubuntu: Incomplete Bug description: When LANG is set to a non-English language with the relevant language pack installed, Kbuild's recordmcount.pl script fails to function correctly when building out-of-tree kernel modules on architectures that do not use the C version of recordmcount (e.g. ppc64le). This can result in invalid kernel modules being built. This was due to the non-C version of recordmcount relying on parsing the output of objdump(1), which can be localized. This is now fixed in the linux-kbuild tree with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux- kbuild.git/commit/?h=kbuild=7b6954a982e7f60af38b835db52a06afc6e4b84c This commit is not in the torvalds/linux.git tree yet, but it would be good to backport the change to the Ubuntu kernel, particularly the linux-headers packages that are used for building out-of-tree kernel modules. Steps to Reproduce: 1. Set LANG to a language other than English (e.g. ja_JP.UTF-8) 2. Make sure that the correct language pack is installed and that localization is working; for example, run a command expected to print an error message, like `cp` with no additional arguments. 3. Install the NVIDIA GPU driver Actual results: The kernel panics when loading the nvidia-modeset kernel module. Expected results: The driver should install and load normally. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828084/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1831945] Re: HDMI/DP audio: ELD not updated on hotplug event
** Patch added: "Patch generated from the upstream commit that fixes this issue" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831945/+attachment/5269215/+files/hda.diff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1831945 Title: HDMI/DP audio: ELD not updated on hotplug event Status in linux package in Ubuntu: New Bug description: When using HDMI or Displayport audio, the EDID-like Data (ELD) fails to update properly when hotplugging or hot-unplugging displays. This in turn prevents tools like the GNOME sound settings control panel from accurately presenting the system's current audio capabilities. How reproducible: Hot plug and hot unplug an audio-capable display and observe the state of the ELDs, either by directly reading the ELD files in /proc/asound/card*/eld* or by examining the available audio output devices in the GNOME sound settings control panel. Steps to Reproduce: 1. Log into a desktop session with no audio-capable displays plugged in 2. Plug in an audio-capable display 3. Open the GNOME sound settings control panel Actual results: The audio-capable display is not selectable as an output device. Expected results: The audio-capable display should be selectable as an output device. Additional info: This bug has been fixed upstream with commit 37a3a98ef601f89100e3bb657fb0e190b857028c. Applying this change alone to the bionic 4.18 HWE kernel is sufficient to allow the expected behavior to occur. It is likely to be sufficient to fix the same bug, assuming it exists, in Cosmic, but neither the presence of the bug nor the sufficiency of the patch were tested. The bug is likely not present in Disco, but this was not tested. This behavior was observed on a system with an NVIDIA GPU running the NVIDIA proprietary driver. The particular NVIDIA GPU on the system is not currently compatible with Nouveau. It is possible and likely that this problem is also reproducible on other systems which do have GPUs that are compatible with Nouveau, and even on systems with HDMI or Displayport connectors being driven by non-NVIDIA GPUs. When the ELD fails to update in response to a hotplug event, an update can be forced by accessing the underlying ALSA codec directly. For example, playing an audio stream directly via ALSA or even just reading from the /proc/asound/cardX/codec#Y file will cause the ELD to become updated. This is of course unnecessary if the patch which fixes the issue is applied, but it does offer a somewhat simple workaround for affected users until the patch can be backported. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831945/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1831945] [NEW] HDMI/DP audio: ELD not updated on hotplug event
Public bug reported: When using HDMI or Displayport audio, the EDID-like Data (ELD) fails to update properly when hotplugging or hot-unplugging displays. This in turn prevents tools like the GNOME sound settings control panel from accurately presenting the system's current audio capabilities. How reproducible: Hot plug and hot unplug an audio-capable display and observe the state of the ELDs, either by directly reading the ELD files in /proc/asound/card*/eld* or by examining the available audio output devices in the GNOME sound settings control panel. Steps to Reproduce: 1. Log into a desktop session with no audio-capable displays plugged in 2. Plug in an audio-capable display 3. Open the GNOME sound settings control panel Actual results: The audio-capable display is not selectable as an output device. Expected results: The audio-capable display should be selectable as an output device. Additional info: This bug has been fixed upstream with commit 37a3a98ef601f89100e3bb657fb0e190b857028c. Applying this change alone to the bionic 4.18 HWE kernel is sufficient to allow the expected behavior to occur. It is likely to be sufficient to fix the same bug, assuming it exists, in Cosmic, but neither the presence of the bug nor the sufficiency of the patch were tested. The bug is likely not present in Disco, but this was not tested. This behavior was observed on a system with an NVIDIA GPU running the NVIDIA proprietary driver. The particular NVIDIA GPU on the system is not currently compatible with Nouveau. It is possible and likely that this problem is also reproducible on other systems which do have GPUs that are compatible with Nouveau, and even on systems with HDMI or Displayport connectors being driven by non-NVIDIA GPUs. When the ELD fails to update in response to a hotplug event, an update can be forced by accessing the underlying ALSA codec directly. For example, playing an audio stream directly via ALSA or even just reading from the /proc/asound/cardX/codec#Y file will cause the ELD to become updated. This is of course unnecessary if the patch which fixes the issue is applied, but it does offer a somewhat simple workaround for affected users until the patch can be backported. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1831945 Title: HDMI/DP audio: ELD not updated on hotplug event Status in linux package in Ubuntu: New Bug description: When using HDMI or Displayport audio, the EDID-like Data (ELD) fails to update properly when hotplugging or hot-unplugging displays. This in turn prevents tools like the GNOME sound settings control panel from accurately presenting the system's current audio capabilities. How reproducible: Hot plug and hot unplug an audio-capable display and observe the state of the ELDs, either by directly reading the ELD files in /proc/asound/card*/eld* or by examining the available audio output devices in the GNOME sound settings control panel. Steps to Reproduce: 1. Log into a desktop session with no audio-capable displays plugged in 2. Plug in an audio-capable display 3. Open the GNOME sound settings control panel Actual results: The audio-capable display is not selectable as an output device. Expected results: The audio-capable display should be selectable as an output device. Additional info: This bug has been fixed upstream with commit 37a3a98ef601f89100e3bb657fb0e190b857028c. Applying this change alone to the bionic 4.18 HWE kernel is sufficient to allow the expected behavior to occur. It is likely to be sufficient to fix the same bug, assuming it exists, in Cosmic, but neither the presence of the bug nor the sufficiency of the patch were tested. The bug is likely not present in Disco, but this was not tested. This behavior was observed on a system with an NVIDIA GPU running the NVIDIA proprietary driver. The particular NVIDIA GPU on the system is not currently compatible with Nouveau. It is possible and likely that this problem is also reproducible on other systems which do have GPUs that are compatible with Nouveau, and even on systems with HDMI or Displayport connectors being driven by non-NVIDIA GPUs. When the ELD fails to update in response to a hotplug event, an update can be forced by accessing the underlying ALSA codec directly. For example, playing an audio stream directly via ALSA or even just reading from the /proc/asound/cardX/codec#Y file will cause the ELD to become updated. This is of course unnecessary if the patch which fixes the issue is applied, but it does offer a somewhat simple workaround for affected users until the patch can be backported. To manage notifications about this bug go to:
[Kernel-packages] [Bug 1830975] [NEW] Old style NVIDIA package installs configuration snippet to an unusual location
Public bug reported: The old-style NVIDIA package (used prior to Bionic) installs an X configuration snippet to: /usr/share/X11/xorg.conf.d/50-nvidia-drm-outputclass.conf/nvidia-drm- outputclass.conf The purpose of this configuration snippet is to configure DRM OutputClass-based driver matching so that the NVIDIA driver can be loaded without needing to explicitly configure it. Due to its location, however, it ends up not being read by the X server. This isn't a problem in distros before Bionic, since up until Artful, the X server was patched to add "nvidia" to the X server's own auto- detected driver list, so the OutputClass-based matching was redundant. However, if a system running Bionic or newer has an NVIDIA driver package from Artful or earlier installed, the location of this file is problematic, as the NVIDIA driver can no longer be autoconfigured from either the X server's internal driver list nor the OutputClass-based matching. Normally, a user wouldn't end up with an old-style driver package on a newer distro, but one possible scenario which could lead to this condition is if an NVIDIA driver package is installed via an external repository (for example, the NVIDIA CUDA repositories) on an Ubuntu version that uses the older packaging format, then the system is upgraded to a newer version that uses the newer packaging format. Third party repositories are disabled as part of the do-release-upgrade process, and the NVIDIA driver package does not get updated. The packages continue to function, but the placement of the nvidia-drm- outputclass.conf file prevents X from selecting the NVIDIA X driver without explicit configuration. I have confirmed that moving this file one level up, so that its parent directory is /usr/share/X11/xorg.conf.d allows the OutputClass-based matching to function as expected. ** Affects: nvidia-graphics-drivers-384 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-384 in Ubuntu. https://bugs.launchpad.net/bugs/1830975 Title: Old style NVIDIA package installs configuration snippet to an unusual location Status in nvidia-graphics-drivers-384 package in Ubuntu: New Bug description: The old-style NVIDIA package (used prior to Bionic) installs an X configuration snippet to: /usr/share/X11/xorg.conf.d/50-nvidia-drm-outputclass.conf/nvidia-drm- outputclass.conf The purpose of this configuration snippet is to configure DRM OutputClass-based driver matching so that the NVIDIA driver can be loaded without needing to explicitly configure it. Due to its location, however, it ends up not being read by the X server. This isn't a problem in distros before Bionic, since up until Artful, the X server was patched to add "nvidia" to the X server's own auto- detected driver list, so the OutputClass-based matching was redundant. However, if a system running Bionic or newer has an NVIDIA driver package from Artful or earlier installed, the location of this file is problematic, as the NVIDIA driver can no longer be autoconfigured from either the X server's internal driver list nor the OutputClass-based matching. Normally, a user wouldn't end up with an old-style driver package on a newer distro, but one possible scenario which could lead to this condition is if an NVIDIA driver package is installed via an external repository (for example, the NVIDIA CUDA repositories) on an Ubuntu version that uses the older packaging format, then the system is upgraded to a newer version that uses the newer packaging format. Third party repositories are disabled as part of the do-release- upgrade process, and the NVIDIA driver package does not get updated. The packages continue to function, but the placement of the nvidia- drm-outputclass.conf file prevents X from selecting the NVIDIA X driver without explicit configuration. I have confirmed that moving this file one level up, so that its parent directory is /usr/share/X11/xorg.conf.d allows the OutputClass- based matching to function as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+bug/1830975/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1828084] Re: Kernel modules generated incorrectly when system is localized to a non-English language
Yes, that's the one. The kbuild maintainer modified the commit message to add a maintainer Signed-off-by line. I would say that any kernel versions that are shipped for actively maintained versions of Ubuntu that support hardware platforms that don't use the C version of recordmcount: for file in arch/*/Kconfig; do if ! grep '^[[:space:]]*select HAVE_C_RECORDMCOUNT $file > /dev/null; then echo $file | cut -f2 -d/; fi; done alpha arc c6x h8300 hexagon ia64 m68k microblaze nds32 nios2 openrisc parisc powerpc riscv s390 sh um unicore32 xtensa This particular problem was observed on powerpc, specifically, ppc64le. Of course, it's up to the Canonical kernel maintainers to decide which kernels could best benefit from a backport; I just wanted to bring the issue and fix to Canonical's attention. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828084 Title: Kernel modules generated incorrectly when system is localized to a non-English language Status in linux package in Ubuntu: Incomplete Bug description: When LANG is set to a non-English language with the relevant language pack installed, Kbuild's recordmcount.pl script fails to function correctly when building out-of-tree kernel modules on architectures that do not use the C version of recordmcount (e.g. ppc64le). This can result in invalid kernel modules being built. This was due to the non-C version of recordmcount relying on parsing the output of objdump(1), which can be localized. This is now fixed in the linux-kbuild tree with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux- kbuild.git/commit/?h=kbuild=7b6954a982e7f60af38b835db52a06afc6e4b84c This commit is not in the torvalds/linux.git tree yet, but it would be good to backport the change to the Ubuntu kernel, particularly the linux-headers packages that are used for building out-of-tree kernel modules. Steps to Reproduce: 1. Set LANG to a language other than English (e.g. ja_JP.UTF-8) 2. Make sure that the correct language pack is installed and that localization is working; for example, run a command expected to print an error message, like `cp` with no additional arguments. 3. Install the NVIDIA GPU driver Actual results: The kernel panics when loading the nvidia-modeset kernel module. Expected results: The driver should install and load normally. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828084/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1828084] [NEW] Kernel modules generated incorrectly when system is localized to a non-English language
Public bug reported: When LANG is set to a non-English language with the relevant language pack installed, Kbuild's recordmcount.pl script fails to function correctly when building out-of-tree kernel modules on architectures that do not use the C version of recordmcount (e.g. ppc64le). This can result in invalid kernel modules being built. This was due to the non-C version of recordmcount relying on parsing the output of objdump(1), which can be localized. This is now fixed in the linux-kbuild tree with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux- kbuild.git/commit/?h=kbuild=7b6954a982e7f60af38b835db52a06afc6e4b84c This commit is not in the torvalds/linux.git tree yet, but it would be good to backport the change to the Ubuntu kernel, particularly the linux-headers packages that are used for building out-of-tree kernel modules. Steps to Reproduce: 1. Set LANG to a language other than English (e.g. ja_JP.UTF-8) 2. Make sure that the correct language pack is installed and that localization is working; for example, run a command expected to print an error message, like `cp` with no additional arguments. 3. Install the NVIDIA GPU driver Actual results: The kernel panics when loading the nvidia-modeset kernel module. Expected results: The driver should install and load normally. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828084 Title: Kernel modules generated incorrectly when system is localized to a non-English language Status in linux package in Ubuntu: New Bug description: When LANG is set to a non-English language with the relevant language pack installed, Kbuild's recordmcount.pl script fails to function correctly when building out-of-tree kernel modules on architectures that do not use the C version of recordmcount (e.g. ppc64le). This can result in invalid kernel modules being built. This was due to the non-C version of recordmcount relying on parsing the output of objdump(1), which can be localized. This is now fixed in the linux-kbuild tree with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux- kbuild.git/commit/?h=kbuild=7b6954a982e7f60af38b835db52a06afc6e4b84c This commit is not in the torvalds/linux.git tree yet, but it would be good to backport the change to the Ubuntu kernel, particularly the linux-headers packages that are used for building out-of-tree kernel modules. Steps to Reproduce: 1. Set LANG to a language other than English (e.g. ja_JP.UTF-8) 2. Make sure that the correct language pack is installed and that localization is working; for example, run a command expected to print an error message, like `cp` with no additional arguments. 3. Install the NVIDIA GPU driver Actual results: The kernel panics when loading the nvidia-modeset kernel module. Expected results: The driver should install and load normally. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1828084/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
I'm confused about the above message. This bug never affected the kernel in Bionic AFAIK. Or is this referring to the HWE kernel for Bionic from Cosmic for 18.04.2? In that case, why isn't this change already included in the HWE kernel as it was imported from Cosmic, rather than needing to be brought in through -proposed first? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid Bug description: SRU Justification Impact: An bug in the secure boot lockdown patches in the 18.10 kernel causes the results of module signature verification to be ignored, allowing modules with no signature or an invalid signature to be loaded. A second bug results in the MOK not being trusted for signing modules, but this bug has been masked by the first bug. Fix: These bugs should be fixed together to avoid regressions in dkms module loading under secure boot. First, fix the latter bug by trusting keys in the kernel's secondary keyring for module signing. Then fix the former bug by removing code related to trusting IMA signatures for loading modules under kernel lockdown. Test Case: Confirm the following behavior under kernel lockdown: 1) Unsigned modules cannot be loaded. 2) Modules signed with an untrusted key cannot be loaded. 3) Modules signed with the kernel's ephemeral build-time key can be loaded. 4) Modules signed with a MOK which has been enrolled with shim can be loaded. I have tested to verify these conditions with the proposed fixes. Regression Potential: This restores the behavior from previous Ubuntu releases, so no regressions are expected wrt those releases. In some cases modules that were loading under lockdown might no longer load, but this is the intended behavior. --- On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion:
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Just to confirm, this is with the 4.18.0-12-generic x86_64 kernel from cosmic-proposed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid Bug description: SRU Justification Impact: An bug in the secure boot lockdown patches in the 18.10 kernel causes the results of module signature verification to be ignored, allowing modules with no signature or an invalid signature to be loaded. A second bug results in the MOK not being trusted for signing modules, but this bug has been masked by the first bug. Fix: These bugs should be fixed together to avoid regressions in dkms module loading under secure boot. First, fix the latter bug by trusting keys in the kernel's secondary keyring for module signing. Then fix the former bug by removing code related to trusting IMA signatures for loading modules under kernel lockdown. Test Case: Confirm the following behavior under kernel lockdown: 1) Unsigned modules cannot be loaded. 2) Modules signed with an untrusted key cannot be loaded. 3) Modules signed with the kernel's ephemeral build-time key can be loaded. 4) Modules signed with a MOK which has been enrolled with shim can be loaded. I have tested to verify these conditions with the proposed fixes. Regression Potential: This restores the behavior from previous Ubuntu releases, so no regressions are expected wrt those releases. In some cases modules that were loading under lockdown might no longer load, but this is the intended behavior. --- On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago)
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Yes, I do see the expected behavior now with signed modules, both when the signing key is enrolled in the MOK (module loads, no verification error) and when it is not enrolled in the MOK (module fails to load due to verification error.) However, the behavior is not quite what I expect when a module is unsigned. The module fails to load, which is expected, but there is no error message in dmesg indicating a missing key, which can make it tricky to determine why the module failed to load, since the failure message printed by modprobe/insmod is simply "Operation not permitted". (It seems the ENOKEY failure is not getting propagated to the user-facing tool.) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid Bug description: SRU Justification Impact: An bug in the secure boot lockdown patches in the 18.10 kernel causes the results of module signature verification to be ignored, allowing modules with no signature or an invalid signature to be loaded. A second bug results in the MOK not being trusted for signing modules, but this bug has been masked by the first bug. Fix: These bugs should be fixed together to avoid regressions in dkms module loading under secure boot. First, fix the latter bug by trusting keys in the kernel's secondary keyring for module signing. Then fix the former bug by removing code related to trusting IMA signatures for loading modules under kernel lockdown. Test Case: Confirm the following behavior under kernel lockdown: 1) Unsigned modules cannot be loaded. 2) Modules signed with an untrusted key cannot be loaded. 3) Modules signed with the kernel's ephemeral build-time key can be loaded. 4) Modules signed with a MOK which has been enrolled with shim can be loaded. I have tested to verify these conditions with the proposed fixes. Regression Potential: This restores the behavior from previous Ubuntu releases, so no regressions are expected wrt those releases. In some cases modules that were loading under lockdown might no longer load, but this is the intended behavior. --- On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Cool, glad you were able to track down the problems. Sorry if my report that module signature verification was disabled and couldn't be re- enabled was misleading. That's what I thought was happening; I didn't think to imagine that the enforcement of the "valid signature required" policy wasn't taking place at all. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67
[Kernel-packages] [Bug 1798863] ProcInterrupts.txt
apport information ** Attachment added: "ProcInterrupts.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204915/+files/ProcInterrupts.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
apport information ** Tags added: apport-collected cosmic ** Description changed: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) - This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into - Ubuntu 18.04, signatures made with the same key are recognized as valid. - Hence, I suspect that something changed in the Ubuntu 18.10 kernel which - is causing signature verification to function in an unexpected way. + This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. + --- + ProblemType: Bug + ApportVersion: 2.20.10-0ubuntu13 + Architecture: amd64 + AudioDevicesInUse: + USERPID ACCESS COMMAND + /dev/snd/controlC0: danix 1729 F pulseaudio + DistroRelease: Ubuntu 18.10 + InstallationDate: Installed on 2018-10-23 (0 days ago) + InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) + NonfreeKernelModules: nvidia_uvm nvidia + Package: linux (not installed) + ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash + ProcFB: 0 inteldrmfb + ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 + ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 + RelatedPackageVersions: + linux-restricted-modules-4.18.0-10-generic N/A + linux-backports-modules-4.18.0-10-generic N/A + linux-firmware 1.175 + Tags: cosmic + Uname: Linux 4.18.0-10-generic x86_64 + UnreportableReason: This report is about a package that is not installed. + UpgradeStatus: No upgrade log present (probably fresh install) + UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo + _MarkForUpload: False + dmi.bios.date: 03/20/2018 + dmi.bios.vendor: HP + dmi.bios.version: P70 Ver. 01.18 + dmi.board.name: 8270 + dmi.board.vendor: HP + dmi.board.version: KBC Version 46.67 + dmi.chassis.type: 10 + dmi.chassis.vendor: HP + dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: + dmi.product.family: 103C_5336AN HP ZBook + dmi.sys.vendor: HP ** Attachment added: "AlsaInfo.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204908/+files/AlsaInfo.txt -- You received this bug notification because you are a member of
[Kernel-packages] [Bug 1798863] IwConfig.txt
apport information ** Attachment added: "IwConfig.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204911/+files/IwConfig.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] PulseList.txt
apport information ** Attachment added: "PulseList.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204917/+files/PulseList.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] Lspci.txt
apport information ** Attachment added: "Lspci.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204912/+files/Lspci.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] ProcCpuinfoMinimal.txt
apport information ** Attachment added: "ProcCpuinfoMinimal.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204914/+files/ProcCpuinfoMinimal.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go
[Kernel-packages] [Bug 1798863] RfKill.txt
apport information ** Attachment added: "RfKill.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204918/+files/RfKill.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] CRDA.txt
apport information ** Attachment added: "CRDA.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204909/+files/CRDA.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] UdevDb.txt
apport information ** Attachment added: "UdevDb.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204919/+files/UdevDb.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] ProcModules.txt
apport information ** Attachment added: "ProcModules.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204916/+files/ProcModules.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] CurrentDmesg.txt
apport information ** Attachment added: "CurrentDmesg.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204910/+files/CurrentDmesg.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] Lsusb.txt
apport information ** Attachment added: "Lsusb.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204913/+files/Lsusb.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] WifiSyslog.txt
apport information ** Attachment added: "WifiSyslog.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204920/+files/WifiSyslog.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 RelatedPackageVersions: linux-restricted-modules-4.18.0-10-generic N/A linux-backports-modules-4.18.0-10-generic N/A linux-firmware 1.175 Tags: cosmic Uname: Linux 4.18.0-10-generic x86_64 UnreportableReason: This report is about a package that is not installed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: False dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to:
[Kernel-packages] [Bug 1798863] [NEW] 18.10 kernel does not appear to validate kernel module signatures correctly
Public bug reported: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring ... [6.628452] nvidia: module verification failed: signature and/or required key missing - tainting kernel ... [6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device number 238 [6.637507] nvidia :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed Oct 10 12:01:53 CDT 2018 (using threaded interrupts) This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 18.04, signatures made with the same key are recognized as valid. Hence, I suspect that something changed in the Ubuntu 18.10 kernel which is causing signature verification to function in an unexpected way. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Attachment added: "apport data from affected system" https://bugs.launchpad.net/bugs/1798863/+attachment/5203120/+files/apport.linux-image-4.18.0-10-generic.c_cz4acm.apport ** Description changed: On a system with Ubuntu 18.10, with secure boot enabled, and a key enrolled in the MOK database, I am observing the following peculiar behaviors: * Signature verification appears to be disabled, and cannot be enabled again. It appeared to be enabled previously, as loading of unsigned modules was failing, and `mokutil --enable-validation` runs without incident; however, upon the next boot when attempting to confirm the change, MokManager prints an error message "Unable to delete Secure Boot state" after completing the password challenge. * As a result of signature verification being disabled, modules signed with untrusted keys taint the kernel instead of failing to load outright. * Regardless of signature verification being enabled or not, it seems that the key enrolled in the MOK is not being used for validating kernel module signatures. Modules signed with the key still fail the signature verification test and taint the kernel, even though the key is visible in the output of `mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows that it's enrolled. Also, a message acknowledging the key appears in dmesg: Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring * Also, somewhat strangely, in this state with module signature verification not being enforced, attempting to load a completely unsigned kernel module suceeds, and doesn't even log a kernel message about a missing/invalid signature, or taint the kernel. Apport report attached, which includes dmesg log showing the kernel acknowledging the key enrolled in the MOK database, and a signature verification failure and subsequent successful loading of a module signed with that key: - [4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key:
[Kernel-packages] [Bug 1241745] Re: [regression] Changing the screen brightness does not work anymore in 319.xx
The problem described in this bug is due to a confirmed regression in the NVIDIA driver. If you are seeing a similar symptom on Intel, that should probably be tracked in a separate bug. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1241745 Title: [regression] Changing the screen brightness does not work anymore in 319.xx Status in “linux” package in Ubuntu: Confirmed Status in “nvidia-graphics-drivers-319” package in Ubuntu: Triaged Bug description: Changing the screen brightness always used to work on my HP Elitebook 8560w -- both with the function keys and in the dialog Brightness Lock in the system settings. The environment light sensor also used to work IIRC. Since the update to 13.10, this stopped working. Methods I have tried that didn't work for adapting the brightness are: * Adding GRUB_CMDLINE_LINUX=acpi_backlight=vendor to /etc/default/grub * Adding GRUB_CMDLINE_LINUX=”acpi_osi=!Windows 2012 to /etc/default/grub Currently I am changing the brightness manually using xrandr --output LVDS-0 --brightness 0.9. However, AFAIK this does not really change the brightness, but only changes the contrast. WORKAROUND: Use nvidia-graphics-drivers-304. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: xorg 1:7.7+1ubuntu6 ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3 Uname: Linux 3.11.0-12-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.60 Wed Sep 25 14:28:26 PDT 2013 GCC version: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) .tmp.unity.support.test.0: ApportVersion: 2.12.5-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Fri Oct 18 19:50:36 2013 DistUpgraded: 2013-10-17 17:20:47,580 DEBUG enabling apt cron job DistroCodename: saucy DistroVariant: ubuntu DkmsStatus: nvidia-319-updates, 319.60, 3.11.0-12-generic, x86_64: installed nvidia-319-updates, 319.60, 3.8.0-31-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: NVIDIA Corporation GF108GLM [Quadro 1000M] [10de:0dfa] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:1631] InstallationDate: Installed on 2013-01-06 (285 days ago) InstallationMedia: Ubuntu 12.10 Quantal Quetzal - Release amd64 (20121017.5) JockeyStatus: kmod:nvidia_319_updates - nvidia_319_updates (Proprietary, Enabled, Not in use) kmod:nvidia_304 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_304_updates - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_319 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) MachineType: Hewlett-Packard HP EliteBook 8560w MarkForUpload: True ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic root=UUID=53f83a14-cacc-48fd-bb4b-354d69eb7f0e ro quiet splash acpi_osi=!Windows 2012 SourcePackage: xorg UpgradeStatus: Upgraded to saucy on 2013-10-17 (1 days ago) dmi.bios.date: 06/11/2012 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68SVD Ver. F.27 dmi.board.name: 1631 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 01.3B dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68SVDVer.F.27:bd06/11/2012:svnHewlett-Packard:pnHPEliteBook8560w:pvrA0001D02:rvnHewlett-Packard:rn1631:rvrKBCVersion01.3B:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP EliteBook 8560w dmi.product.version: A0001D02 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.46-1 version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A version.xserver-xorg-core: xserver-xorg-core 2:1.14.3-3ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.904-0ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.9-2ubuntu1 xserver.bootTime: Fri Oct 18 19:39:07 2013 xserver.configfile: default xserver.errors:
[Kernel-packages] [Bug 1241745] Re: [regression] Changing the screen brightness does not work anymore in 319.xx
Not to my knowledge: that changelog entry refers to adding an additional interface via the NV-CONTROL API to the existing backlight functionality. The problem is that the existing backlight functionality is now broken on some laptops, so it doesn't make a difference whether it's exposed through a new API or not. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1241745 Title: [regression] Changing the screen brightness does not work anymore in 319.xx Status in “linux” package in Ubuntu: Confirmed Status in “nvidia-graphics-drivers-319” package in Ubuntu: Triaged Bug description: Changing the screen brightness always used to work on my HP Elitebook 8560w -- both with the function keys and in the dialog Brightness Lock in the system settings. The environment light sensor also used to work IIRC. Since the update to 13.10, this stopped working. Methods I have tried that didn't work for adapting the brightness are: * Adding GRUB_CMDLINE_LINUX=acpi_backlight=vendor to /etc/default/grub * Adding GRUB_CMDLINE_LINUX=”acpi_osi=!Windows 2012 to /etc/default/grub Currently I am changing the brightness manually using xrandr --output LVDS-0 --brightness 0.9. However, AFAIK this does not really change the brightness, but only changes the contrast. WORKAROUND: Use nvidia-graphics-drivers-304. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: xorg 1:7.7+1ubuntu6 ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3 Uname: Linux 3.11.0-12-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.60 Wed Sep 25 14:28:26 PDT 2013 GCC version: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) .tmp.unity.support.test.0: ApportVersion: 2.12.5-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Fri Oct 18 19:50:36 2013 DistUpgraded: 2013-10-17 17:20:47,580 DEBUG enabling apt cron job DistroCodename: saucy DistroVariant: ubuntu DkmsStatus: nvidia-319-updates, 319.60, 3.11.0-12-generic, x86_64: installed nvidia-319-updates, 319.60, 3.8.0-31-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: NVIDIA Corporation GF108GLM [Quadro 1000M] [10de:0dfa] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:1631] InstallationDate: Installed on 2013-01-06 (285 days ago) InstallationMedia: Ubuntu 12.10 Quantal Quetzal - Release amd64 (20121017.5) JockeyStatus: kmod:nvidia_319_updates - nvidia_319_updates (Proprietary, Enabled, Not in use) kmod:nvidia_304 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_304_updates - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_319 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) MachineType: Hewlett-Packard HP EliteBook 8560w MarkForUpload: True ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic root=UUID=53f83a14-cacc-48fd-bb4b-354d69eb7f0e ro quiet splash acpi_osi=!Windows 2012 SourcePackage: xorg UpgradeStatus: Upgraded to saucy on 2013-10-17 (1 days ago) dmi.bios.date: 06/11/2012 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68SVD Ver. F.27 dmi.board.name: 1631 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 01.3B dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68SVDVer.F.27:bd06/11/2012:svnHewlett-Packard:pnHPEliteBook8560w:pvrA0001D02:rvnHewlett-Packard:rn1631:rvrKBCVersion01.3B:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP EliteBook 8560w dmi.product.version: A0001D02 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.46-1 version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A version.xserver-xorg-core: xserver-xorg-core 2:1.14.3-3ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.904-0ubuntu2 version.xserver-xorg-video-nouveau:
[Kernel-packages] [Bug 1241745] Re: [regression] Changing the screen brightness does not work anymore in 319.xx
Sorry, at the moment we don't have an ETA for a fix. It's not likely to be fixed in the immediate future. I've added a note to the bug report on the NVIDIA bug tracker as a reminder to update this Launchpad thread when we have a fix in hand. The only workaround I'm currently aware of is to use an older driver, but older drivers may not be compatible with newer X servers and kernels. The 304.xx series is maintained as a legacy branch, so it would be compatible with newer kernel / X server versions, and unless your hardware is especially new, there's a good chance that a 304.xx driver will work for you. The recently released 304.116 driver, for example, is compatible with Xorg up to 1.14 and Linux up to 3.12. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1241745 Title: [regression] Changing the screen brightness does not work anymore in 319.xx Status in “linux” package in Ubuntu: Confirmed Status in “nvidia-graphics-drivers-319” package in Ubuntu: Triaged Bug description: Changing the screen brightness always used to work on my HP Elitebook 8560w -- both with the function keys and in the dialog Brightness Lock in the system settings. The environment light sensor also used to work IIRC. Since the update to 13.10, this stopped working. Methods I have tried that didn't work for adapting the brightness are: * Adding GRUB_CMDLINE_LINUX=acpi_backlight=vendor to /etc/default/grub * Adding GRUB_CMDLINE_LINUX=”acpi_osi=!Windows 2012 to /etc/default/grub Currently I am changing the brightness manually using xrandr --output LVDS-0 --brightness 0.9. However, AFAIK this does not really change the brightness, but only changes the contrast. WORKAROUND: Use nvidia-graphics-drivers-304. ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: xorg 1:7.7+1ubuntu6 ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3 Uname: Linux 3.11.0-12-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 319.60 Wed Sep 25 14:28:26 PDT 2013 GCC version: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu8) .tmp.unity.support.test.0: ApportVersion: 2.12.5-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true Date: Fri Oct 18 19:50:36 2013 DistUpgraded: 2013-10-17 17:20:47,580 DEBUG enabling apt cron job DistroCodename: saucy DistroVariant: ubuntu DkmsStatus: nvidia-319-updates, 319.60, 3.11.0-12-generic, x86_64: installed nvidia-319-updates, 319.60, 3.8.0-31-generic, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: NVIDIA Corporation GF108GLM [Quadro 1000M] [10de:0dfa] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:1631] InstallationDate: Installed on 2013-01-06 (285 days ago) InstallationMedia: Ubuntu 12.10 Quantal Quetzal - Release amd64 (20121017.5) JockeyStatus: kmod:nvidia_319_updates - nvidia_319_updates (Proprietary, Enabled, Not in use) kmod:nvidia_304 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_304_updates - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) kmod:nvidia_319 - NVIDIA binary Xorg driver, kernel module and VDPAU library (Proprietary, Disabled, Not in use) MachineType: Hewlett-Packard HP EliteBook 8560w MarkForUpload: True ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic root=UUID=53f83a14-cacc-48fd-bb4b-354d69eb7f0e ro quiet splash acpi_osi=!Windows 2012 SourcePackage: xorg UpgradeStatus: Upgraded to saucy on 2013-10-17 (1 days ago) dmi.bios.date: 06/11/2012 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68SVD Ver. F.27 dmi.board.name: 1631 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 01.3B dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68SVDVer.F.27:bd06/11/2012:svnHewlett-Packard:pnHPEliteBook8560w:pvrA0001D02:rvnHewlett-Packard:rn1631:rvrKBCVersion01.3B:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP EliteBook 8560w dmi.product.version: A0001D02 dmi.sys.vendor: Hewlett-Packard version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.46-1 version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3
