Kernel 5.4 lockdown smbios-thermal

[scristofaro]

Hello,
After upgraded Kubuntu from 18.04 to 20.04 on my Dell XPS 9370, I had a lot of message in dmesg (syslog), 3 for seconds:

May 11 16:04:37 PC kernel: [11151.455983] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
May 11 16:04:37 PC kernel: [11151.518526] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
May 11 16:04:37 PC kernel: [11151.582267] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
May 11 16:04:39 PC kernel: [11153.460670] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
May 11 16:04:39 PC kernel: [11153.520345] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
May 11 16:04:39 PC kernel: [11153.596393] Lockdown: smbios-thermal-: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7

I know the issue is due to Secure Boot, but I would not disable it. Everything works fine, so I would like to know if is possible to limit the access of smbios-thermal to /dev/mem,kmem,port, whereas their lack of access is not causing problems.
Thanks in advance,
Salvatore

System Info:

- Distributor ID: Kubuntu
- Description: Kubuntu Focal Fossa
- Release: 20.04
- Kernel: Linux u-27469 5.4.0-26-generic

Build Info

2.4.3

[superm1]

What is calling smbios-thermal-ctl on your machine?

[scristofaro]

I don't know exactly. I believe it was Intel P-State and CPU Freq Manager, but ever disabling it the messages doesn't disappear.
I need to uninstall smbios-utils (sudo apt remove smbios-utils) to remove these messages. If i install again the package, messages come back!
The only two power utils I can find are:

root        1142  0.0  0.0 252504 10172 ?        Ssl  12:58   0:02 /usr/lib/upower/upowerd
users+    2240  0.0  0.2 404112 38968 ?        Sl   12:59   0:03 /usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdevil

[superm1]

Did you install this thing? https://github.com/jsalatas/plasma-pstate/

If so it definitely calls it.
https://github.com/jsalatas/plasma-pstate/blob/c3bb44c0aebf57c72b33cccefd935b9d1d89ccba/gr.ictpro.jsalatas.plasma.pstate/contents/code/set_prefs.sh

You should probably remove it and instead switch to thermald +dptfxtract.

[scristofaro]

Yes, it was plasma-pstate. I uninstall this plasma widget. But I can reproduce the issue everytime I run
sudo smbios-thermal-ctl -g

[superm1]

Yes, it was plasma-pstate. I uninstall this plasma widget. But I can reproduce the issue everytime I run
sudo smbios-thermal-ctl -g

Correct, the kernel locks down certain accesses that libsmbios tries to make.

[scristofaro]

I know that is a very personal issue, but it possible to disable these accesses with an option (safe mode for example)?
I do a strace and I found only a single access only to /dev/mem
However I have not identified the function :-(

openat(AT_FDCWD, "/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0400, st_size=5843, ...}) = 0
fstat(3, {st_mode=S_IFREG|0400, st_size=5843, ...}) = 0
lseek(3, 4096, SEEK_SET)                = 4096
read(3, "\4\0\0\346\4\346\4\1\0\347\4\347\4\0\0\354\4\354\4\1\0\355\4\355\4\0\0\0\5\0\5\377"..., 1747) = 1747
lseek(3, 0, SEEK_SET)                   = 0
read(3, "\0\30\0\0\1\2\0\360\3\377\200\232\231?\1\0\23\0\203\17\1\f\377\377Dell Inc"..., 4096) = 4096
read(3, "\4\0\0\346\4\346\4\1\0\347\4\347\4\0\0\354\4\354\4\1\0\355\4\355\4\0\0\0\5\0\5\377"..., 4096) = 1747
close(3)                                = 0
openat(AT_FDCWD, "`/dev/mem", O_RDONLY)  = -1 EPERM (Operazione non permessa)
openat(AT_FDCWD, "/dev/wmi/dell-smbios", O_RDONLY) = 3
fstat(3, {st_mode=S_IFCHR|0444, st_rdev=makedev(0xa, 0x39), ...}) = 0

[superm1]

The tool still works in the lockdown scenario right? I would think it should since it accesses over /dev/wmi/dell-smbios instead.

If so, then I do think it's possible to remove the access it tries to /dev/mem. I'd be happy to review a pull request if you want to do one. Basically the access to /dev/mem happens in the memory area:
https://github.com/dell/libsmbios/blob/dab5dfd01dba12fc48ff7697fc066c7856b6df2f/src/libsmbios_c/memory/memory_linux.c.

I suspect (but don't recall for sure) that's called from here:

libsmbios/src/libsmbios_c/smbios/smbios_linux.c

Line 186 in f4031c3

int ret = memory_read(block, fp, sizeof(struct smbios_table_entry_point));

But you'll probably need to walk through a debugger to find the proper call chain that leads. I think that a simple check if in lockdown mode to ignore /skip that stuff would be fine. Or remove the calls entirely if using WMI instead.

[scristofaro]

Hello, i made some debug

Problem is not in this line:

libsmbios/src/libsmbios_c/smbios/smbios_linux.c

Line 186 in f4031c3

int ret = memory_read(block, fp, sizeof(struct smbios_table_entry_point));

but in this one:

libsmbios/src/libsmbios_c/system_info/id_byte.c

Line 47 in f4031c3

ret = memory_read(strBuf, DELL_SYSTEM_STRING_LOC, DELL_SYSTEM_STRING_LEN-1);

change it in
//ret = memory_read(strBuf, DELL_SYSTEM_STRING_LOC, DELL_SYSTEM_STRING_LEN-1);
resolve the problem.
It's impossible to read from DELL_SYSTEM_STRING_LOC (0xFE076) in lockdown mode. So it might be useful to add a check.

It could be useful to read the Lockdown Kernel state from:
/sys/kernel/security/lockdown

In my case:
none [integrity] confidentiality

Integrity and Confidentiality don't allow to read from memory
So, the check option should be:

if file exists and could be read
       if value is none  ([none])
               ret = memory_read(strBuf, DELL_SYSTEM_STRING_LOC, DELL_SYSTEM_STRING_LEN-1);

[superm1]

Appreciate your debugging!

For Dell platforms w/ SMBIOS 3.0 that field is actually already filled out as part of SKU Number field.
In sysfs this is /sys/class/dmi/id/product_sku.

I think the proper solution should be to add a new function that tries to read product_sku as first attempt here:

libsmbios/src/libsmbios_c/system_info/id_byte.c

Line 193 in f4031c3

DellIdByteFunctions[] = {