Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753836AbeAGMwF (ORCPT + 1 other); Sun, 7 Jan 2018 07:52:05 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:41769 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752886AbeAGMwD (ORCPT ); Sun, 7 Jan 2018 07:52:03 -0500 X-Google-Smtp-Source: ACJfBotjp4jtJ0/7GkOJEyQPWF6QPh3JYSvku1EWTcqBDmGd0F9hdscuWYZtsnC2asgLSrA0kN9vtQ== Subject: Re: Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs To: Theodore Ts'o , Alan Cox , "linux-kernel@vger.kernel.org" References: <20180106200232.67387c5a@alans-desktop> <20180107122918.GE2404@thunk.org> From: Avi Kivity Organization: ScyllaDB Message-ID: Date: Sun, 7 Jan 2018 14:51:59 +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: <20180107122918.GE2404@thunk.org> 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 02:29 PM, Theodore Ts'o wrote: > On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote: >> I think capabilities will work just as well with cgroups. The container >> manager will set CAP_PAYLOAD to payload containers; and if those run an init >> system or a container manager themselves, they'll drop CAP_PAYLOAD for all >> process/sub-containers but their payloads. > The reason why cgroups are better is Spectre can be used to steal > information from within the same privilege level --- e.g., you could > use Javascript to steal a user's Coindesk credentials or Lastpass > data, which is going to be *way* more lucrative than trying to mine > cryptocurrency in the sly in a user's browser. :-) > > As a result, you probably want Spectre mitigations to be enabled in a > root process --- which means capabilities aren't the right answer. > > I don't see the connection. The browser wouldn't run with CAP_PAYLOAD set. In a desktop system, only init retains CAP_PAYLOAD. On a server that runs one application (and some supporting processes), only init and that one application have CAP_PAYLOAD (if the sysadmin makes it so). On a containerized server that happens to run just one application, init will retain CAP_PAYLOAD, as well as the process in the container (if the sysadmin makes it so). On a containerized server that happens to run just one application, which itself runs an init system, the two inits will retain CAP_PAYLOAD, as well as the application process (if the sysadmin makes it so).