linux-kernel - Re: [PATCH V40 12/29] x86: Lock down IO port access when the kernel is locked down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220105101437.GA32516@srcf.ucam.org>
Date:   Wed, 5 Jan 2022 10:14:37 +0000
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     jmorris@...ei.org, linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        David Howells <dhowells@...hat.com>,
        Kees Cook <keescook@...omium.org>, x86@...nel.org
Subject: Re: [PATCH V40 12/29] x86: Lock down IO port access when the kernel
 is locked down

On Wed, Jan 05, 2022 at 06:05:26PM +0800, Kai-Heng Feng wrote:
> On Wed, Jan 5, 2022 at 3:20 PM Matthew Garrett <mjg59@...f.ucam.org> wrote:
> >
> > On Wed, Jan 05, 2022 at 02:57:57PM +0800, Kai-Heng Feng wrote:
> >
> > > 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.

But have a signed bootloader? Which releases?

> > 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().

Because having the ability to do port io allows you to tamper with the 
running kernel and disable all the other security boundaries, making 
them pointless. Many PCI devices have a port IO side channel into MMIO 
BARs for use in early boot, so if an attacker can fill that BAR as they 
wish and then modify the BAR to map it into the kernel address space 
(and fix up the bridges appropriately), or if the port IO interface can 
be used to trigger DMA, the outcomes are pretty bad. The point of 
lockdown is to disable every plausible interface for userland (even uid 
0) to have access to any interfaces that would let them insert modified 
code into ring 0 - port IO is definitely one of those interfaces. An 
attacker could just take a kernel that allows ioperm(), add an initramfs 
containing their payload, boot, hotpatch the kernel to disable lockdown, 
and then kexec into their backdoored payload.

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

Sounds good.