Message-ID: <CA+X5Wn4zOrkt=jnD0QP-S9uPQ2=gU_8MNcquoe_Q4fvyzCZudQ@mail.gmail.com>
Date:   Fri, 5 Jan 2018 07:29:43 -0500
From:   james harvey <jamespharvey20@...il.com>
To:     "Woodhouse, David" <dwmw@...zon.co.uk>
Cc:     "jikos@...nel.org" <jikos@...nel.org>,
        "elena.reshetova@...el.com" <elena.reshetova@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "gregkh@...ux-foundation.org" <gregkh@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "andi@...stfloor.org" <andi@...stfloor.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>
Subject: Re: Avoid speculative indirect calls in kernel

On Fri, Jan 5, 2018 at 5:40 AM, Woodhouse, David <dwmw@...zon.co.uk> wrote:
> On Thu, 2018-01-04 at 21:01 -0500, james harvey wrote:
>>
>>
>> I understand the GCC patches being discussed will fix the
>> vulnerability because newly compiled kernels will be compiled with a
>> GCC with these patches.
>
> The GCC patches work by eliminating all indirect branches, thus
> avoiding 'variant 2' of the three problems which have been discovered.
>
> Note that we also need to eliminate all the indirect branches which
> occurred in native assembler code too, and provide the 'thunks' that
> GCC uses instead, which is why there's a series of kernel patches to go
> with it.
>
> But building a kernel this way is *only* sufficient to protect the
> kernel. Attacks between userspace processes are still possible — you
> need the updated microcode, with branch-predictor flushes/restrictions,
> to protect existing userspace processes from each other.
>
>> But, are the GCC patches being discussed also expected to fix the
>> vulnerability because user binaries will be compiled using them?
>
> It would be possible to do that. Sensitive userspace processes could be
> built this way, rendering them invulnerable to 'variant 2' attacks
> without the kernel having to use the microcode features.
>
>> In such case, a binary could be maliciously changed back, or a custom GCC
>> made with the patches reverted.
>
> If the attacker can replace the sensitive binary, or replace the
> compiler with which the sensitive binary was compiled, then we have
> other problems. I'm not going to lose sleep over that.
>
>
> Note that *none* of this addresses 'variant 1'. There's a separate
> patch series which addresses likely 'variant 1 gadgets' in the kernel,
> which I haven't seen posted in public yet. And I'm not sure what we do
> about that for userspace except extending the existing Coverity ruleset
> and teaching GCC to emit barriers automatically in the right places,
> which is a bit far-fetched right now. Elena?
> Amazon Web Services UK Limited. Registered in England and Wales with registration number 08650665 and which has its registered office at 60 Holborn Viaduct, London EC1A 2FD, United Kingdom.

I could have written more clearly.  What I'm getting at is if any of
the GCC patches are intended to prevent an exploit from being able to
be attempted, rather than making binaries immune from attacks.  So, I
don't mean being able to modify a sensitive binary or the system's
compiler.  I mean someone has non-root SSH access.  Compiles GCC with
whatever patches wind up for variant 1-3 reverted, or uses an old
version.  Leaves their custom compiled GCC in their user directory, to
compile malicious code.  Executes the compiled malicious code from
their user directory.  (Or, compiles a malicious program on their own
system compatible in architecture, kernel and library versions, using
GCC without new patches, and just copies over the binary to their user
directory to execute.)  Or, malicious customer with a VM on a shared
machine who has root access within their VM, reverting GCC patches
attempting to see into the host or other VM's on the machine.

Powered by blists - more mailing lists