From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Willy Tarreau <w@1wt.eu>
Cc: Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
torvalds@linux-foundation.org, stable@vger.kernel.org,
lwn@lwn.net, Jiri Slaby <jslaby@suse.cz>
Subject: Re: Linux 4.4.110
Date: Fri, 5 Jan 2018 19:58:04 +0000 [thread overview]
Message-ID: <20180105195804.5388fbd4@alans-desktop> (raw)
In-Reply-To: <20180105184249.GF4254@1wt.eu>
> It depends by whom :-) We benchmarked this machine a while ago at 93k
> connections per second on 4.9 on a single process and now I'm seeing
> about 60k for a single process. I don't want to digress too much about
> numbers now as the test conditions certainly differ a bit, I'll have
> to rerun more detailed ones later. For 99.9% of the users it will not
> be noticeable. Those having to fight DDoS will certainly notice it.
> I'm pretty sure we'll run with pti=off at least at the beginning.
Are you running pti on the vm kernels or the host kernel or both ?
> I'm currently testing a completely different approach for systems like
> these running basically a single task. The idea is to limit rdtsc to
> privileged processes only. I just discovered that my libc happily uses
The javascript attack in the paper does not use rdtsc, and the techniques
to deal with rdtsc disabling are well known and used in other existing
attacks.
> For this reason, people considering pti=off as the only solution might
> sometimes prefer this one as a small improvement (and it could also
> stop other classes of future attacks, maybe something for KSPP later).
For a large class of environments where you are only running code that you
trust (or at least if anyone evil changes you've got much bigger problems)
that is probably a rational approach anyway.
Alan
next prev parent reply other threads:[~2018-01-05 19:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 14:54 Linux 4.4.110 Greg KH
2018-01-05 14:54 ` Greg KH
2018-01-05 15:55 ` Willy Tarreau
2018-01-05 18:02 ` Greg KH
2018-01-05 18:42 ` Willy Tarreau
2018-01-05 19:58 ` Alan Cox [this message]
2018-01-05 20:24 ` Willy Tarreau
2018-01-06 13:16 ` Willy Tarreau
2018-01-08 9:16 ` Willy Tarreau
2018-01-08 9:29 ` Greg KH
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=20180105195804.5388fbd4@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lwn@lwn.net \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/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;
as well as URLs for NNTP newsgroup(s).