Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934069AbeAJMSL (ORCPT + 1 other); Wed, 10 Jan 2018 07:18:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41594 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934045AbeAJMSJ (ORCPT ); Wed, 10 Jan 2018 07:18:09 -0500 Date: Wed, 10 Jan 2018 13:17:55 +0100 From: Andrea Arcangeli To: David Woodhouse Cc: Peter Zijlstra , Dave Hansen , Thomas Gleixner , LKML , Linus Torvalds , x86@kernel.org, Borislav Petkov , Tim Chen , Andi Kleen , Greg KH , Andy Lutomirski , Arjan Van De Ven Subject: Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code Message-ID: <20180110121755.GD9706@redhat.com> References: <20180110010652.404145126@linutronix.de> <20180110011350.855878109@linutronix.de> <20180110092234.GY29822@worktop.programming.kicks-ass.net> <1515576479.22302.81.camel@infradead.org> <20180110115419.GA9706@redhat.com> <1515585534.22302.122.camel@infradead.org> <20180110120158.GB9706@redhat.com> <1515586174.22302.126.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1515586174.22302.126.camel@infradead.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 10 Jan 2018 12:18:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 10, 2018 at 12:09:34PM +0000, David Woodhouse wrote: > That is not consistent with the documentation I've seen, which Intel > have so far utterly failed to publish AFAICT. > > "a near indirect jump/call/return may be affected by code in a less privileged > prediction mode that executed AFTER IBRS mode was last written with a value of 1" You must have misunderstood the context there, or the above text is wrong to begin with. > The kernel is only protected from branch targets set in userspace > *BEFORE* the IBRS mode was last set to 1. If you set it to 1, then > leave it like that while you run userspace and then kernel code again, > you are not protected. I'm sure you've got it wrong, that would be crazy if it would be the case. Even from an implementation standpoint IBRS just means stop speculating through branch prediction, there's no way they can add this separation between ring 0 and ring 3 when it didn't exist to begin with. RSB had it with SMEP and in fact there's no need to do stuff_RSB with SMEP enabled in cr4 and we alternative it out in kernel entry on host and guest, but we still have to do that in vmexit. IBP/BTB had nothing like, which is why user ring 3 can attack host ring 0. It will have it and also separating guest from host but in the future. Plus IBRS can be set at will by guest mode, if guest kernel is malicious it will let guest userland run with IBRS on. You can't trust the guest kernel to begin with. So it would make IBRS totally useless for KVM to set in vmexit if you were right about that. In any case, we've a ibrs_enabled 0 ibpb_enabled 2 that would achieve full security if you were right, but I think you got it all wrong about IBRS and rings. Second: IBRS means Indirect Branch Restricted Speculation, the speculation through branch prediction is restricted while it's set. It's inconceivable that they add ring knowledge to a part that is couldn't be helped by SMEP in the first place that had at least some ring separation when enabled.