Bugzilla – Bug 1212141
[lockdown] KBD_NUMLOCK="bios" is broken: numlockbios: /dev/mem,kmem,port is restricted
Last modified: 2024-03-15 11:35:37 UTC
During boot of locked down kernel (Kernel:HEAD currently, TW in few weeks): Lockdown: numlockbios: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7 So KBD_NUMLOCK="bios" will not work. strace /usr/libexec/kbd/numlockbios shows: openat(AT_FDCWD, "/dev/mem", O_RDONLY) = -1 EPERM (Operation not permitted)
Added by sbrabec in: https://build.opensuse.org/request/show/563909
Hi Jiri. Not completely sure what do to here. As far as I can tell there is no other interface to get the bios NumLock information from the kernel. Looked at hwinfo to see how it is done there and it seems it also reads from /dev/mem. Could you test and confirm that hwinfo --bios throws the same error? Also looked at how the kernel handles this and it seems that the keyboard should already be initialized by the kernel using the bios settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2d0b7a061bfddd27155c7dcd53f365d9dc0c7c3 However I'll need to test this further to make sure that the config is actually kept in userspace ttys. The other option would be to drop support for the KBD_NUMLOCK="bios" option entirely, and only keep "yes" or "no" options. Would also have to be removed in Yast.
(In reply to Antonio Teixeira from comment #2) > Hi Jiri. Hi, > Not completely sure what do to here. As far as I can tell there is no other > interface to get the bios NumLock information from the kernel. > > Looked at hwinfo to see how it is done there and it seems it also reads from > /dev/mem. Could you test and confirm that hwinfo --bios throws the same > error? Yes, it's the very same. > Also looked at how the kernel handles this and it seems that the keyboard > should already be initialized by the kernel using the bios settings: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=b2d0b7a061bfddd27155c7dcd53f365d9dc0c7c3 Correct. I am actually not sure what happens on EFI. The above code is likely not executed there at all, as loader jumps directly to one of startups in kernel/entry.S. > However I'll need to test this further to make sure that the config is > actually kept in userspace ttys. > > The other option would be to drop support for the KBD_NUMLOCK="bios" option > entirely, and only keep "yes" or "no" options. Would also have to be removed > in Yast. That makes sense.
This feature was not added by me. I just ported a very old feature to systemd. Fri Jun 14 12:58:10 CEST 2002 - sndirsch@suse.de - boot.setup: handle Numlock depending on BIOS setting if KBD_NUMLOCK is set to "bios" - sysconfig.keyboard: added "bios" to KBD_NUMLOCK description This feature needs to read the BIOS data area. Is there a better way, how to do it? It basically does: fdmem = open("/dev/mem", O_RDONLY); lseek(fdmem, 0x497, SEEK_SET); read (fdmem, &c, sizeof(char)); if (c & 0x02) printf("on\n"); else printf("off\n");
Perhaps reading /sys/class/leds/input*::numlock/brightness should do the job.
Isn't that arbitrarily set by the kernel rather than reflecting the BIOS state?
Oh, right. Dunno then.
In such case, I suggest to remove this feature, as it cannot be fixed to work on modern systems. kbd: Remove unmaintained SUSE customizations https://jira.suse.com/browse/PED-7977 (SUSE internal link)