From: Andi Kleen <ak@suse.de>
To: Andrea Arcangeli <andrea@cpushare.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: disable tsc with seccomp
Date: Sat, 5 Nov 2005 18:04:08 +0100 [thread overview]
Message-ID: <200511051804.08306.ak@suse.de> (raw)
In-Reply-To: <20051105163134.GC14064@opteron.random>
On Saturday 05 November 2005 17:31, Andrea Arcangeli wrote:
> On Sat, Nov 05, 2005 at 05:12:09PM +0100, Andi Kleen wrote:
> > It is normally on on all x86-64 systems.
>
> Can the performance counters be disabled for seccomp only right?
Yes, there is a bit to disable reading performance counters in ring 3.
But I promise you to complain about a patch to add setting it in the context
switch too :)
> > I definitely don't want any code like this in the context switch. It is
> > critical and I don't want to pollute fast paths with stuff like this
> > that nobody needs.
>
> 287 registered CPUShare users will appreciate to compute more securely
> thanks to this feature (about 10 up at any given time), and once I start
> allowing transactions I hope much more users will need this (it's not
> finished yet).
I don't believe they need it - the side channel attack is too theoretical for
their use case.
> We have in the kernel lots of features that slowdown a bit and that
> benefit only a part of the userbase. Even kmap only benefits people with
>
> >1G of ram. Even the security_* api in the syscalls only benefit a part
>
> of the userbase. There are infinite other examples. The point is that
> none of this is measurable,
LSM was actually quite measurable on some systems, the indirect
calls really hurt on IA64 on some of the network benchmarks.
> _especially_ this one in the context switch,
> context switches aren't as frequent as syscalls! It's only two
> cachelines at every context switch, and they might be hot
If they're not hot for some reason (e.g. cache pig in userspace) you're
talking about 1000+ cycles.
> Plus Andrew would have never allowed it to go in, if this could have
> impacted performance, you also should know this can't slowdown anything
> and you're just talking about theory.
The person talking about theory is you in my opinion with this basically
theoretical attack.
> Of course if 1000 other people also adds their feature to the context
> switch then it might become measurable, but this is the first time we
> had to change the context switch to add more security on per-task basis,
Better to stamp out any such attempts in the roots.
-Andi
next prev parent reply other threads:[~2005-11-05 17:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-05 13:47 disable tsc with seccomp Andrea Arcangeli
2005-11-05 15:37 ` Andi Kleen
2005-11-05 16:07 ` Andrea Arcangeli
2005-11-05 16:12 ` Andi Kleen
2005-11-05 16:31 ` Andrea Arcangeli
2005-11-05 17:04 ` Andi Kleen [this message]
2005-11-06 1:55 ` Andrea Arcangeli
2005-11-21 16:43 ` Andrea Arcangeli
2005-11-21 17:05 ` Andi Kleen
2005-11-21 17:16 ` Andrea Arcangeli
2005-11-21 17:24 ` Andi Kleen
2005-11-21 17:38 ` Andrea Arcangeli
2005-11-21 18:40 ` Andrea Arcangeli
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=200511051804.08306.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=andrea@cpushare.com \
--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