I tried to load a kernel module (v4l2loopback-dkms from a copr package FWIW) I got permission denied and dmesg had a message to look at `man kernel_lockdown`. I did and it says: ``` If the kernel is appropriately configured, lockdown may be lifted by typing the appropriate sequence on a directly attached physical keyboard. For x86 machines, this is SysRq+x. ``` Hmmm, that sounds better/easier than disabling secure boot (which I assume is what is triggering the lockdown). But `SysRq+x` doesn't work: in `dmesg` I see: ``` [ 572.368731] sysrq: HELP : loglevel(0-9) reboot(b) crash(c) terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i) thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l) show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p) show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V) show-blocked-tasks(w) dump-ftrace-buffer(z) ``` (Note there is no "x" in that list.) My system is x86_64: maybe they *literally* mean x86 (and thus not x86_64)? But why would that be? Or is there some config I need to do let this key work (it does say "appropriately configured": perhaps Fedora's kernel is not)? My kernel: ``` Linux x1c7 5.6.14-300.fc32.x86_64 #1 SMP Wed May 20 20:47:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ```
Ah, perhaps it has been disabled. https://bugzilla.redhat.com/show_bug.cgi?id=1800859 Then we should really patch that man page as its the first place I got to (being new to lockdown, and just following dmesg advice).
The default is for SYSRQ to be disabled: $ fgrep SYSRQ /boot/config-5.6.13-200.fc31.x86_64 CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x0 CONFIG_MAGIC_SYSRQ_SERIAL=y However: $ cat /proc/sys/kernel/sysrq 16 See, also: include/linux/sysrq.h https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/sysrq.h?h=v5.7-rc7 Documentation: Linux Magic System Request Key Hacks https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
Try this: # echo 1 > /proc/sys/kernel/sysrq $ journalctl --no-hostname -f alt-sysrq-m # dump current memory info However, alt-sysrq-x still only displays a help message. And the help message doesn't list "x" as an option. Tested with 5.6.13-200.fc31.x86_64.
Sorry that I wasn't clear above: I mean sysrq+x specifically has been disabled in #1800859, independent of what I might write into /proc. In fact comment 3 by Wilhelm Wijkander already says: > On a different note, kernel_lockdown(7) in f31 still seems to reference the sysrq workaround. So I guess my bug is a dupe of that comment :-) I'll leave it open as it would be good to fix that man-page.
Thanks for your clarification. The result is that there is no documented way to disable the kernel_lockdown feature. That makes it impossible for "sensors-detect" (in "lm_sensors") to detect some hardware monitoring chips, because the kernel reports: May 15 19:56:25 kernel: Lockdown: sensors-detect: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.