Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756674AbeAHKx4 (ORCPT + 1 other); Mon, 8 Jan 2018 05:53:56 -0500 Received: from mail-ua0-f193.google.com ([209.85.217.193]:41361 "EHLO mail-ua0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756573AbeAHKxz (ORCPT ); Mon, 8 Jan 2018 05:53:55 -0500 X-Google-Smtp-Source: ACJfBosqajnA5IKb+OZ6cI8ehCKaE5tZuZTyhw/Z2GfjbaowWrk0jPZdcrfiSx3mvICCGKlCJSK8/LbfpVd5DvEJCtM= MIME-Version: 1.0 In-Reply-To: <1515408317.7317.31.camel@infradead.org> References: <1515363085-4219-1-git-send-email-dwmw@amazon.co.uk> <1515408317.7317.31.camel@infradead.org> From: Paul Turner Date: Mon, 8 Jan 2018 02:53:23 -0800 Message-ID: Subject: Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel To: David Woodhouse Cc: Andi Kleen , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , Thomas Gleixner , Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , One Thousand Gnomes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 8, 2018 at 2:45 AM, David Woodhouse wrote: > On Mon, 2018-01-08 at 02:34 -0800, Paul Turner wrote: >> One detail that is missing is that we still need RSB refill in some >> cases. >> This is not because the retpoline sequence itself will underflow (it >> is actually guaranteed not to, since it consumes only RSB entries >> that it generates. >> But either to avoid poisoning of the RSB entries themselves, or to >> avoid the hardware turning to alternate predictors on RSB underflow. >> >> Enumerating the cases we care about: >> >> • user->kernel in the absence of SMEP: >> In the absence of SMEP, we must worry about user-generated RSB >> entries being consumable by kernel execution. >> Generally speaking, for synchronous execution this will not occur >> (e.g. syscall, interrupt), however, one important case remains. >> When we context switch between two threads, we should flush the RSB >> so that execution generated from the unbalanced return path on the >> thread that we just scheduled into, cannot consume RSB entries >> potentially installed by the prior thread. > > Or IBPB here, yes? That's what we had in the original patch set when > retpoline came last, and what I assume will be put back again once we > *finally* get our act together and reinstate the full set of microcode > patches. IBPB is *much* more expensive than the sequence I suggested. If the kernel has been protected with a retpoline compilation, it is much faster to not use IBPB here; we only need to prevent ret-poisoning in this case. > >> kernel->kernel independent of SMEP: >> While much harder to coordinate, facilities such as eBPF potentially >> allow exploitable return targets to be created. >> Generally speaking (particularly if eBPF has been disabled) the risk >> is _much_ lower here, since we can only return into kernel execution >> that was already occurring on another thread (which could e.g. likely >> be attacked there directly independent of RSB poisoning.) >> >> guest->hypervisor, independent of SMEP: >> For guest ring0 -> host ring0 transitions, it is possible that the >> tagging only includes that the entry was only generated in a ring0 >> context. Meaning that a guest generated entry may be consumed by the >> host. This admits: > > We are also stuffing the RSB on vmexit in the IBRS/IBPB patch set, > aren't we? A) I am enumerating all of the cases for completeness. It was missed by many that this detail was necessary on this patch, independently of IBRS. B) On the parts duplicated in (A), for specifics that are contributory to correctness in both cases, we should not hand-wave over the fact that they may or may not be covered by another patch-set. Users need to understand what's required for complete protection. Particularly if they are backporting.