Date: Sun, 7 Jan 2018 14:36:28 +0000
From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Willy Tarreau <w@1wt.eu>
Cc: Avi Kivity <avi@scylladb.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation
 costs
Message-ID: <20180107143628.3cd15813@alans-desktop>
In-Reply-To: <20180106202433.GB9075@1wt.eu>
References: <a5398c4e-be02-0de6-5c76-c37320011eef@scylladb.com>
        <20180106202433.GB9075@1wt.eu>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

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

What I struggle to see is why I'd want to nominate specific processes for
this except in very special cases (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.

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)