Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753968AbeAGPPY (ORCPT + 1 other); Sun, 7 Jan 2018 10:15:24 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:43146 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752898AbeAGPPW (ORCPT ); Sun, 7 Jan 2018 10:15:22 -0500 X-Google-Smtp-Source: ACJfBotMIr6HtNox29SyCfV+mR+FSKAqT8yXO/yhuVZoeD9YJ8DdM+Jy/pGSjrldJM4Aa0BMtRZB3g== Subject: Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs To: Alan Cox , Willy Tarreau Cc: "linux-kernel@vger.kernel.org" References: <20180106202433.GB9075@1wt.eu> <20180107143628.3cd15813@alans-desktop> From: Avi Kivity Organization: ScyllaDB Message-ID: <72b496d5-14a3-527e-69a3-63c04615eda4@scylladb.com> Date: Sun, 7 Jan 2018 17:15:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180107143628.3cd15813@alans-desktop> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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)