linux-kernel - Re: Linux 4.4.110

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180105202431.GA4811@1wt.eu>
Date:   Fri, 5 Jan 2018 21:24:31 +0100
From:   Willy Tarreau <w@....eu>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        torvalds@...ux-foundation.org, stable@...r.kernel.org, lwn@....net,
        Jiri Slaby <jslaby@...e.cz>
Subject: Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 07:58:04PM +0000, Alan Cox wrote:
> > 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 ?

First, just to avoid confusion, numbers above were on bare metal
(i7-4790K, having PCID). But as I said, I didn't necessarily apply
the exact same test protocol as my goal was to quickly fire a long
test to run for the week-end. In previous tests (pti vs non-pti) I
only measured 17% difference.

For the tests I ran in KVM, PTI was only in the VM, the host was my
laptop that has not yet been rebooted, hence is not protected yet.
And here I used the same test protocol with/without PTI. The numbers
I have in mind were respectively 30.3k conn/s and 18.3k (with pti).

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

from what I've seen it uses the precise time reported by the browser which
itself uses clock_gettime() (which we can thus control as well). But I
might have missed certain points, there has been a lot to read this week...

> and the techniques
> to deal with rdtsc disabling are well known and used in other existing
> attacks.

Yes i've tested one of them for the spectre poc, but it really did not
work well, leading to about 1 among 10 bytes only to be valid. In fact
either you run the counter thread on the other sibling of the same core
and it significantly perturbates the local activity, or you run it on
another core, and the time it takes to retrieve the time requires some
L1+L2 traversal. I'm not saying it doesn't work at all, I'm saying that
the accuracy is highly degraded and that can turn something 100%
reproducible into something requiring a long time to run, making the
attack more noticeable (and possibly letting observed data degrade
during the period).

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

For now yes unfortunately :-/

Willy