Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753388AbeADPtL (ORCPT + 1 other); Thu, 4 Jan 2018 10:49:11 -0500 Received: from smtp.ctxuk.citrix.com ([185.25.65.24]:31687 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751471AbeADPtJ (ORCPT ); Thu, 4 Jan 2018 10:49:09 -0500 X-IronPort-AV: E=Sophos;i="5.45,507,1508803200"; d="scan'208";a="65594170" Subject: Re: [PATCH v3 10/13] x86/retpoline/pvops: Convert assembler indirect jumps To: Juergen Gross , David Woodhouse , CC: Paul Turner , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , , Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , References: <20180104143710.8961-1-dwmw@amazon.co.uk> <20180104143710.8961-10-dwmw@amazon.co.uk> <380dc816-1732-90dc-268e-4a8c3e7ccc7d@suse.com> From: Andrew Cooper Message-ID: <3c1bcc6d-d509-c48e-32ab-a24596f03e2f@citrix.com> Date: Thu, 4 Jan 2018 15:18:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <380dc816-1732-90dc-268e-4a8c3e7ccc7d@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 04/01/18 15:02, Juergen Gross wrote: > On 04/01/18 15:37, David Woodhouse wrote: >> Convert pvops invocations to use non-speculative call sequences, when >> CONFIG_RETPOLINE is enabled. >> >> There is scope for future optimisation here — once the pvops methods are >> actually set, we could just turn the damn things into *direct* jumps. >> But this is perfectly sufficient for now, without that added complexity. > I don't see the need to modify the pvops calls. > > All indirect calls are replaced by either direct calls or other code > long before any user code is active. > > For modules the replacements are in place before the module is being > used. When booting virtualised, sibling hyperthreads can arrange VM-to-VM SP2 attacks. One mitigation though is to consider if there is any interesting data to leak that early during boot. ~Andrew