Subject: Re: Avoid speculative indirect calls in kernel
To: David Woodhouse <dwmw2@infradead.org>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "pavel@ucw.cz" <pavel@ucw.cz>
Cc: "tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "andi@firstfloor.org" <andi@firstfloor.org>,
        "gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
        "dave.hansen@intel.com" <dave.hansen@intel.com>,
        "gregkh@linux-foundation.org" <gregkh@linux-foundation.org>,
        Andrea Arcangeli <aarcange@redhat.com>
References: <20180103230934.15788-1-andi@firstfloor.org>
 <CA+55aFzCocoK+4kxAUEhaxxba4RTv3ewBmhiZ8Osc9iDkBtCEQ@mail.gmail.com>
 <e64025e6-9c4f-703d-cb69-29eeb9cc16bd@redhat.com> <20180104114231.GB1702@amd>
 <1515066469.12987.112.camel@amazon.co.uk>
 <94b12025-b27c-04d2-8726-c07a3af6b265@redhat.com>
 <7a3584c6-0c00-d807-5130-13d1f4b34102@citrix.com>
 <1515079777.12987.149.camel@amazon.co.uk>
 <1515082507.12987.159.camel@infradead.org>
From: Tom Lendacky <thomas.lendacky@amd.com>
Message-ID: <cc2711b0-0278-986f-0fe9-9a993506c47d@amd.com>
Date: Thu, 4 Jan 2018 14:00:11 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1515082507.12987.159.camel@infradead.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2018 20:00:15.3659 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ca2d911-9ee1-431c-1d98-08d553adc683
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1143
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>


On 1/4/2018 10:15 AM, David Woodhouse wrote:
> On Thu, 2018-01-04 at 15:29 +0000, Woodhouse, David wrote:
>>
>>> With the GCC -mindirect-branch=thunk-external support, and microcode,
>>> Xen will make a boot-time choice between using Retpoline, Lfence (which
>>> is the better AMD option, and more performant than retpoline), or IBRS
>>> on Skylake and newer processors where it is strictly necessary, as well
>>> as using IBPB whenever available.
>>
>> I need to pull in the AMD lfence alternative for retpoline, giving us a
>> 3-way choice of the existing retpoline thunk, "lfence; jmp *%\reg", and
>> a bare "jmp *%\reg".
> 
> I think I can abuse X86_FEATURE_SYSCALL for that, right? So it would
> look something like this:
> 
>  --- a/arch/x86/lib/retpoline.S
> +++ b/arch/x86/lib/retpoline.S
> @@ -12,7 +12,7 @@
>  
>  ENTRY(__x86.indirect_thunk.\reg)
>         CFI_STARTPROC
> -       ALTERNATIVE "call 2f", __stringify(jmp *%\reg), X86_BUG_NO_RETPOLINE
> +       ALTERNATIVE_2 "call 2f", __stringify(lfence;jmp *%\reg), X86_FEATURE_SYSCALL, __stringify(jmp *%\reg), X86_BUG_NO_RETPOLINE
>  1:
>         lfence
>         ASM_UNREACHABLE
> 
> 
> However, I would very much like to see a categorical statement from AMD
> that the lfence is sufficient in all cases. Remember, Intel were saying
> that too for a while, before finding that it was not *quite* good
> enough.

Yes, lfence is sufficient.  As long as the target is in the register
before the lfence and we jump through the register all is good, i.e.:

Include a dispatch serializing instruction after the load of an indirect
branch target. For instance, change this code:

1: jmp *[rax] ; jump to address pointed to by RAX

To this:

1: mov [rax], rax ; load target address
2: lfence ; dispatch serializing instruction
3: jmp *rax

The processor will stop dispatching instructions until all older
instructions have returned their results and are capable of being retired
by the processor. At this point the branch target will be in the general
purpose register (rax in this example) and available at dispatch for
execution such that the speculative execution window is not large enough
to be exploited.

Thanks,
Tom

>