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]

Message-ID: <72b496d5-14a3-527e-69a3-63c04615eda4@scylladb.com>
Date:   Sun, 7 Jan 2018 17:15:18 +0200
From:   Avi Kivity <avi@...lladb.com>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>, Willy Tarreau <w@....eu>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation
 costs

On 01/07/2018 04:36 PM, Alan Cox wrote:
>> 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'm still trying to work out what cases there are for this. I can see the
> cases for pti-off. I've got minecraft servers for example where there
> isn't anyone running untrusted code on the box (*) and the only data of
> value is owned by the minecraft processes. If someone gets to the point
> pti matters then I already lost.

You don't want, say, a local out-of-process dns resolver compromised and 
exploited, then PTI used to read all of the machine's memory.

>
> What I struggle to see is why I'd want to nominate specific processes for
> this except in very special cases

Suppose you are running a database (I hope you'll agree that's not a 
special case). Then, "all of your data was stolen but the good news is 
that your ssh keys are safe" is not something that brightens your day. 
Your ssh keys are worth a lot less than your data.

In that case disabling PTI just for the database can be a good trade-off 
between security and performance. You lose almost nothing by disabling 
PTI for the database, yet you're still secure* from a remote exploit in 
any supporting processes, or from a malicious local user.

* as secure as you were with full PTI

>   (like your packet generator). Even then
> it would make me nervous as the packet generator if that trusted is
> effectively CAP_SYS_RAWIO or close to it and can steal any ssh keys or
> similar on that guest.
>
> I still prefer cgroups because once you include the branch predictions it
> suddenly becomes very interesting to be able to say 'this pile of stuff
> trusts itself' and avoid user/user protection costs while keeping
> user/kernel.

By "this pile of stuff" do you mean a group of mutually-trusting 
processes? I don't see how that can be implemented, because any 
cross-process switch has to cross the kernel boundary. In any case a 
cross-process switch will destroy the effectiveness of branch prediction 
history, so preserving it doesn't buy you much.

>
> Alan
> (*) I am sure that java programs can do sandbox breaking via spectre just
> as js can. Bonus points to anyone however who can do spectre through java
> from redstone 8)