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
next prev 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