Subject: Re: [PATCH v3 10/13] x86/retpoline/pvops: Convert assembler indirect
 jumps
To: Andrew Cooper <andrew.cooper3@citrix.com>,
        David Woodhouse <dwmw@amazon.co.uk>, ak@linux.intel.com
Cc: Paul Turner <pjt@google.com>, LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linux-foundation.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>, tglx@linutronix.de,
        Kees Cook <keescook@google.com>,
        Rik van Riel <riel@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Jiri Kosina <jikos@kernel.org>, gnomes@lxorguk.ukuu.org.uk
References: <20180104143710.8961-1-dwmw@amazon.co.uk>
 <20180104143710.8961-10-dwmw@amazon.co.uk>
 <380dc816-1732-90dc-268e-4a8c3e7ccc7d@suse.com>
 <3c1bcc6d-d509-c48e-32ab-a24596f03e2f@citrix.com>
From: Juergen Gross <jgross@suse.com>
Message-ID: <f5280efe-e5e1-9ba7-c299-11b0f402564a@suse.com>
Date: Thu, 4 Jan 2018 17:04:29 +0100
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: <3c1bcc6d-d509-c48e-32ab-a24596f03e2f@citrix.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org

On 04/01/18 16:18, Andrew Cooper wrote:
> 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.

Right. And if you are able to detect a booting VM in the other
hyperthread, obtain enough information about its kernel layout and
extract the information via statistical methods in the very short time
frame of the boot before pvops patching takes place. Not to forget the
vast amount of data the booting VM will pull through the caches making
side channel attacks a rather flaky endeavor...

I'd opt for leaving pvops calls untouched. The Reviewed-by: I gave for
the patch was just for its correctness. :-)


Juergen