coreboot

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.

I uploaded a patch, could you test it out? https://review.coreboot.org/c/coreboot/+/69981

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.

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:

1. Install the following packages using apt: sudo apt install build-essential git
2. Download the coreboot source code: git clone https://review.coreboot.org/coreboot
3. Go to the superiotool source: cd coreboot/util/superiotool
4. Download my patch: git fetch https://review.coreboot.org/coreboot refs/changes/81/69981/4 && git checkout -b change-69981 FETCH_HEAD
5. Compile superiotool: make
6. Try running superiotool again sudo ./superiotool

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.

Hmm, that's interesting. I'll have to look into this further.

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.

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

Do you need any more additional information to help you solve this problem?

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.

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.

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.

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 exist

Thank 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...

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"?

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

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?

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] confidentiality

Modern 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?