Bug #440
opensuperiotool tells you to run it as root and stops even when ran as root
0%
Description
On ubuntu 22.10:
sudo superiotool
iopl: Function not implemented
Superiotool must be run as root.
superiotool tells you to run it as root and stops even when ran as root
Updated by Nicholas Chin about 2 years ago
Ah, iopl is deprecated and I guess more systems have started removing it. I remember someone having the same issue with nvramtool before, but I guess I never got around to posting a patch to fix it. It should be replaced with ioperm.
That error message is printed if iopl returns an error, and I guess the assumption was that if it errored you most likely didn't have the permissions to call it. But now the issue is that iopl isn't implemented in the first place.
Updated by Nicholas Chin about 2 years ago
I uploaded a patch, could you test it out? https://review.coreboot.org/c/coreboot/+/69981
Updated by J Nky about 2 years ago
Nicholas Chin wrote in #note-2:
I uploaded a patch, could you test it out? https://review.coreboot.org/c/coreboot/+/69981
Unfortunately I have no idea how to do it. I'm having like 2 brain cells at most and all I can do is to get prebuilt package using apt install
:)
BTW, thank you very much for fast response.
Updated by Nicholas Chin about 2 years ago
J Nky wrote in #note-3:
Unfortunately I have no idea how to do it. I'm having like 2 brain cells at most and all I can do is to get prebuilt package using
apt install
:)
Hmm, so I'm assuming you are using superiotool from the coreboot-utils package?
In that case, try these steps:
- Install the following packages using apt:
sudo apt install build-essential git
- Download the coreboot source code:
git clone https://review.coreboot.org/coreboot
- Go to the superiotool source:
cd coreboot/util/superiotool
- Download my patch:
git fetch https://review.coreboot.org/coreboot refs/changes/81/69981/4 && git checkout -b change-69981 FETCH_HEAD
- Compile superiotool:
make
- Try running superiotool again
sudo ./superiotool
Updated by J Nky about 2 years ago
Hmm, so I'm assuming you are using superiotool from the coreboot-utils package?
Yes. Thanks to your instructions and after installation of libpci-dev
i was able to build it.
Now i get this when i trying to run it:
root@LAPTOP:~/coreboot/util/superiotool# sudo ./superiotool
ioperm: Function not implemented
Superiotool must be run as root.
But I only tested it on WSL2. Later I will try on Ubuntu itself.
UPD: Exactly the same on Ubuntu 22.10.
Updated by Nicholas Chin about 2 years ago
Hmm, that's interesting. I'll have to look into this further.
Updated by Nicholas Chin about 2 years ago
J Nky wrote in #note-5:
But I only tested it on WSL2. Later I will try on Ubuntu itself.
UPD: Exactly the same on Ubuntu 22.10.
Ah, I'm not surprised that iopl or ioperm are apparently not implemented in WSL2, but if it's still doing that in an Ubuntu install on the hardware then that is strange. I just tried it on Ubuntu 22.10 in a VM, but I don't seem to get that error, even when using iopl. What laptop are you running this on? Just in case there's some hardware dependent thing going on.
Updated by J Nky about 2 years ago
Nicholas Chin wrote in #note-7:
What laptop are you running this on? Just in case there's some hardware dependent thing going on.
Asus Zenbook 13 UM325UA
Updated by J Nky about 2 years ago
Do you need any more additional information to help you solve this problem?
Updated by Nicholas Chin about 2 years ago
J Nky wrote in #note-9:
Do you need any more additional information to help you solve this problem?
Not at the moment, I want to experiment/research a bit more later to see if I can reproduce the issue, and I'm a bit short on time right now.
Updated by Nicholas Chin about 2 years ago
J Nky wrote in #note-9:
Do you need any more additional information to help you solve this problem?
Could you run uname -r
and post the result so that I can see what kernel you are running? Could you also check if the file /proc/config.gz
(contains the config for the kernel) exists, and if so, could you post it? From what I've found, the iopl and ioperm system calls are controlled by the same kernel config option, so if both don't work that might suggest that this option is disabled in the kernel.
Updated by J Nky about 2 years ago
Nicholas Chin wrote in #note-11:
Could you run
uname -r
and post the result so that I can see what kernel you are running? Could you also check if the file/proc/config.gz
(contains the config for the kernel) exists, and if so, could you post it? From what I've found, the iopl and ioperm system calls are controlled by the same kernel config option, so if both don't work that might suggest that this option is disabled in the kernel.
On Ubuntu 22.10 in WSL2:
uname -r
5.10.102.1-microsoft-standard-WSL2
/proc/config.gz
:
# CONFIG_X86_IOPL_IOPERM is not set
On Ubuntu 22.10 Desktop:
uname -r
5.19.0-21-generic
/proc/config.gz
does not exist
Thank you.
Updated by Martin Roth almost 2 years ago
- Status changed from New to Response Needed
I'm not able to reproduce it on a genuine linux system. I don't think it's surprising that it wouldn't work on WSL as windows probably doesn't let the WSL linux kernel get close to real hardware.
Can anyone else reproduce this issue?
Updated by Nicholas Chin almost 2 years ago
J Nky wrote in #note-12:
Nicholas Chin wrote in #note-11:
Could you run
uname -r
and post the result so that I can see what kernel you are running? Could you also check if the file/proc/config.gz
(contains the config for the kernel) exists, and if so, could you post it? From what I've found, the iopl and ioperm system calls are controlled by the same kernel config option, so if both don't work that might suggest that this option is disabled in the kernel.
On Ubuntu 22.10 Desktop:uname -r 5.19.0-21-generic
/proc/config.gz
does not existThank you.
Apparently on Ubuntu the config can be found under /boot/config-5.19.0-21-generic
. Could you check that? That said, when I check that file on a live Ubuntu 21.10 ISO with that same kernel, CONFIG_X86_IOPL_IOPERM
is enabled...
Updated by Nicholas Chin almost 2 years ago
J Nky wrote in #note-5:
Hmm, so I'm assuming you are using superiotool from the coreboot-utils package?
Yes. Thanks to your instructions and after installation of
libpci-dev
i was able to build it.Now i get this when i trying to run it:
root@LAPTOP:~/coreboot/util/superiotool# sudo ./superiotool ioperm: Function not implemented Superiotool must be run as root.
But I only tested it on WSL2. Later I will try on Ubuntu itself.
UPD: Exactly the same on Ubuntu 22.10.
When you tested it on an actual Ubuntu 22.10 install, did it return "Function not implemented" or "Operation not permitted"?
Updated by J Nky almost 2 years ago
Nicholas Chin wrote in #note-15:
J Nky wrote in #note-5:
Hmm, so I'm assuming you are using superiotool from the coreboot-utils package?
Yes. Thanks to your instructions and after installation of
libpci-dev
i was able to build it.Now i get this when i trying to run it:
root@LAPTOP:~/coreboot/util/superiotool# sudo ./superiotool ioperm: Function not implemented Superiotool must be run as root.
But I only tested it on WSL2. Later I will try on Ubuntu itself.
UPD: Exactly the same on Ubuntu 22.10.
When you tested it on an actual Ubuntu 22.10 install, did it return "Function not implemented" or "Operation not permitted"?
I used Ubuntu 22.10 from USB stick.
ioperm: Function not implemented
Updated by Nicholas Chin almost 2 years ago
Nicholas Chin wrote in #note-14:
Apparently on Ubuntu the config can be found under
/boot/config-5.19.0-21-generic
. Could you check that? That said, when I check that file on a live Ubuntu 21.10 ISO with that same kernel,CONFIG_X86_IOPL_IOPERM
is enabled...
Could you also check this file to see the value of CONFIG_X86_IOPL_IOPERM
?
Updated by Nicholas Chin over 1 year ago
I found this comment on this GitHub issue, which might explain the strange behaviour we are seeing: https://github.com/zamaudio/intelmetool/issues/20#issuecomment-751562837
I got this error too, and tracked the issue down.
iopl() returns an error EPERM (Operation not permitted) - even when invoked as root - if the kernel is in "lockdown mode". One of the things that lockdown mode does is disables userspace access to privileged I/O.
You can check if you are in lockdown mode as follows:
$ cat /sys/kernel/security/lockdown
none [integrity] confidentialityModern Linux distributions - such as Debian, in my case - will automatically enter lockdown mode (integrity) when the kernel is booted with EFI Secure Boot enabled. To fix the issue I simply disabled Secure Boot and restarted my machine.
Could you check if your system is in lockdown mode and if you have secure boot enabled?