linux-kernel - Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 6 Jan 2018 21:24:33 +0100
From:   Willy Tarreau <w@....eu>
To:     Avi Kivity <avi@...lladb.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation
 costs

Hi Avi,

On Sat, Jan 06, 2018 at 09:33:28PM +0200, Avi Kivity wrote:
> Meltdown and Spectre mitigations focus on protecting the kernel from a
> hostile userspace. However, it's not a given that the kernel is the most
> important target in the system. It is common in server workloads that a
> single userspace application contains the valuable data on a system, and if
> it were hostile, the game would already be over, without the need to
> compromise the kernel.
>
> In these workloads, a single application performs most system calls, and so
> it pays the cost of protection, without benefiting from it directly (since
> it is the target, rather than the kernel).

Definitely :-)

> I propose to create a new capability, CAP_PAYLOAD, that allows the system
> administrator to designate an application as the main workload in that
> system. Other processes (like sshd or monitoring daemons) exist to support
> it, and so it makes sense to protect the rest of the system from their being
> compromised.

Initially I was thinking about letting applications disable PTI using
prctl() when running under a certain capability (I initially thought
about CAP_SYSADMIN though I changed my mind). One advantage of
proceeding like this is that it would have to be explicitly implemented
in the application, which limits the risk of running by default.

I later thought that we could use CAP_RAWIO for this, given that such
processes already have access to the hardware anyway. We could even
imagine not switching the page tables on such a capability without
requiring prctl(), though it would mean that processes running as root
(as is often found on a number of servers) would automatically present
a risk for the system. But maybe CAP_RAWIO + prctl() could be a good
solution.

I'm interested in participating to working on such a solution, given
that haproxy is severely impacted by "pti=on" and that for now we'll
have to run with "pti=off" on the whole system until a more suitable
solution is found.

I'd rather not rush anything and let things calm down for a while to
avoid adding disturbance to the current situation. But I'm willing to
continue this discussion and even test patches.

Cheers,
Willy