netdev - Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

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: <CA+55aFz0tsreoa=5Ud2noFCpng-dizLBhT9WU9asyhpLfjdcYA@mail.gmail.com>
Date:   Mon, 8 Jan 2018 10:49:01 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     Alexei Starovoitov <ast@...com>,
        "David S . Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jann Horn <jannh@...gle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Elena Reshetova <elena.reshetova@...el.com>,
        Alan Cox <alan@...ux.intel.com>,
        Network Development <netdev@...r.kernel.org>,
        kernel-team <kernel-team@...com>,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

On Mon, Jan 8, 2018 at 9:05 AM, Mark Rutland <mark.rutland@....com> wrote:
>
> I'm a little worried that in the presence of some CPU/compiler
> optimisations, the masking may effectively be skipped under speculation.
> So I'm not sure how robust this is going to be.

Honestly, I think the masking is a hell of a lot more robust than any
of the "official" fixes.

More generic data speculation (as opposed to control speculation) is

 (a) mainly academic masturbation

 (b) hasn't even been shown to be a good idea even in _theory_ yet
(except for the "completely unreal hardware" kind of theory where
people assume some data oracle)

 (c) isn't actually done in any real CPU's today that I'm aware of
(unless you want to call the return stack data speculation).

and the thing is, we should really not then worry about "... but maybe
future CPU's will be more aggressive", which is the traditional worry
in these kinds of cases.

Why? Because quite honestly, any future CPU's that are more aggressive
about speculating things like this are broken shit that we should call
out as such, and tell people not to use.

Seriously.

In this particular case, we should be very much aware of future CPU's
being more _constrained_, because CPU vendors had better start taking
this thing into account.

So the masking approach is FUNDAMENTALLY SAFER than the "let's try to
limit control speculation".

If somebody can point to a CPU that actually speculates across an
address masking operation, I will be very surprised. And unless you
can point to that, then stop trying to dismiss the masking approach.

The only thing we need to be really really careful about is to make
sure that the mask generation itself is not in a control speculation
path.

IOW, the mask really has to be a true data dependency, and has to be
generated arithmetically. Because if the mask generation has a control
dependency on it, then obviously that defeats the whole "make sure we
don't have control speculation" approach.

                   Linus