On Wed, Jan 5, 2022 at 3:20 PM Matthew Garrett [off-list ref] wrote:

On Wed, Jan 05, 2022 at 02:57:57PM +0800, Kai-Heng Feng wrote:

quoted

The affected system from the customer has SecureBoot enabled (and
hence lockdown), and the kernel upgrade surprisingly broke ioperm()
usage.

Which kernel was being used that was signed but didn't implement
lockdown? That sounds, uh, bad.

It was upgraded from older distro release. Older kernels don't have lockdown.

quoted

The userspace program is proprietary so I can't share it here.

Ok. Are you able to describe anything about what it does so we can
figure out a better solution?

quoted

Basically this patch makes ioperm() a noop on SecureBoot enabled x86 systems.
If reverting is not an option, what else can we do to circumvent the regression?

There's two main choices:

1) Disable secure boot on the system in question - if there's a need to
run userland that can do arbitrary port IO then secure boot isn't
providing any meaningful security benefit in any case.

How so?
Other security features are still incredible valuable, we don't want
to toss them out just because someone has to use ioperm().

2) Implement a kernel driver that abstracts the hardware access away
from userland, and ensures that all the accesses are performed in a safe
way.

Doing port IO from userland is almost always a terrible idea - it
usually involves indexed accesses (you write an address to one port and
then write or read data from another), and if two processes are trying
to do this simultaneously (either because SMP or because one process
gets preempted after writing the address but before accessing the data
register), and in that case you can end up with accesses to the wrong
register as a result. You really want this sort of thing to be mediated
by the kernel, both from a safety perspective and to ensure appropriate
synchronisation.

Agree, let me start a discussion with them.

Kai-Heng