public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
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
Date: Sun, 7 Jan 2018 18:26:37 +0100	[thread overview]
Message-ID: <20180107172637.GA9772@1wt.eu> (raw)
In-Reply-To: <20180107143628.3cd15813@alans-desktop>

On Sun, Jan 07, 2018 at 02:36:28PM +0000, Alan Cox wrote:
> 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.

Sure but we can also say that a process with CAP_SYS_RAWIO can manipulate
the hardware using iopl() and reprogram memory controllers, PCI bridges
and various stuff to have direct access wherever it wants. That's why I
thought that grouping the risks reduces the attack surface in the end.

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

To be honnest, I don't know what it would imply in terms of management
(for the admin). Also, I'm really focused on the extra work to add to
syscalls, which should remain very minimalistic. Checking a flag on the
current task sounds reasonable. I don't know how far we might have to
go with cgroups. I remember a very long time ago you once todl me "we
have fast syscalls", I'd like this statement to remain true for those
who continue to rely on this property ;-)

Willy

  parent reply	other threads:[~2018-01-07 17:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-06 19:33 Proposal: CAP_PAYLOAD to reduce Meltdown and Spectre mitigation costs Avi Kivity
2018-01-06 20:02 ` Alan Cox
2018-01-07  9:16   ` Avi Kivity
2018-01-07 12:29     ` Theodore Ts'o
2018-01-07 12:34       ` Ozgur
2018-01-07 12:51       ` Avi Kivity
2018-01-07 18:06         ` Theodore Ts'o
2018-01-06 20:24 ` Willy Tarreau
2018-01-07  9:14   ` Avi Kivity
2018-01-07 17:39     ` Willy Tarreau
2018-01-07 14:36   ` Alan Cox
2018-01-07 15:15     ` Avi Kivity
2018-01-07 17:26     ` Willy Tarreau [this message]
2018-01-08  1:33 ` Casey Schaufler
2018-01-18 22:49 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180107172637.GA9772@1wt.eu \
    --to=w@1wt.eu \
    --cc=avi@scylladb.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox