Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs

[Avi Kivity]

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)