Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAPweEDyvUdGvwy4u5qoA2QgDow0npZBMqjeMiU2RqzrJ_q4Omw@mail.gmail.com>
 <CAPweEDyV487=EWqAibc5g_yhtuvy3w2qabCSOqh32q38rrXLSw@mail.gmail.com> <20190118150706.7b1b9e31@alans-desktop>
In-Reply-To: <20190118150706.7b1b9e31@alans-desktop>
From:   Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Sat, 19 Jan 2019 11:06:28 +0000
Message-ID: <CAPweEDw34REx15uQ50pRoXZ+FfLxegcvxm8DN7323NrgOCsZKA@mail.gmail.com>
Subject: Re: [RFC] spectre hardware-software cooperative mitigation
To:     Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Friday, January 18, 2019, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>
> > This is going to be a mammoth task. The alternatives are to continue
> > as things are, which is a mess that cannot be cleaned up by either of
> > (mutually exclusive) hardware or software alone.
> >
> > Thoughts and feedback appreciated.
>
> You need to be talking to the JIT developers not asking here I think.
> Speculative attacks in JIT environments is a topic an order of magnitude
> or more complex than the kernel cases because there isn't even process
> isolation between the JIT, JIT engin eand support logic.
>

Hi Alan thanks for engaging on this.  Deep breath: it's everything.
OpenSSL, linux kernel, uboot, JIT developers, PAM, system calls,
interrupts, exceptions, everything. Anywhere any time there is a
transition (of any kind, not just JIT environments) from trusted code
to arbitrary untrusted code, whether it be linux kernel, uboot,
applications, BIOSes, literally and absolutely anything and
everything, on every processor that is OoO, regardless of ISA.

In essence our basic fundamental assumptions about security separation
are... gone [for OoO processors].

Since I wrote the OP I found that the RISCV BOOM team had done some
research, and also concluded that explicitly called speculation
"fences" were the sanest solution. Link to discussion:

https://groups.google.com/forum/?nomobile=true#!topic/riscv-boom/yxDwmpjtQrE

Where my expertise runs out is whether it should be libc6 that calls
the firebreak instruction (or if one does not exist, a set of 100 NOPs
or whatever is found to be best suited for a given OoO processor), or
whether it should be the linux kernel that does so, perhaps as part of
the context switch point.

An OoO processor that has since been designed to clear the entire
speculation state on a context switch, interrupt or exception clearly
would not need to call the firebreak (fence) instruction in the linux
kernel context switch (from kernelspace to userspace as you do not
want info to leak from privileged to non-privileged) however those
that do not have such capability just as clearly would need to.

Whether the same fence should be called on the switch from userspace
to kernelspace? Honestly I do not know, I believe it would depend on
the level of paranoia :) Do you trust the linux kernel not to be
compromised, if it is, do you consider it Game Over already, that sort
of thing. Don't know the answer there.

So, yes, JIT definitely more complex, fence will definitely help...
however it is everywhere, *all* software needs to engage on this and
begin the long arduous process of designing, agreeing and then
implementing a sane mitigation strategy.

Yes BIOSes too ( Anyone still think proprietary BIOSes are a good idea? Intel?)

Or, we can all go back to using 25+ year old x86 processors (486s,
yay! Anyone still got an original OLPC, with the Geode LX500, or even
a Vortex86?), or use ARM Cortex A7 32 bit, Cortex A53 64 bit, or
MIPS64, anything that's in-order that can be found... *if* they can be
found... :)

l.