From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22EE2C7EE2A for ; Thu, 1 Jun 2023 00:42:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230344AbjFAAmJ (ORCPT ); Wed, 31 May 2023 20:42:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjFAAmH (ORCPT ); Wed, 31 May 2023 20:42:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 24427123; Wed, 31 May 2023 17:42:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B546C63B8E; Thu, 1 Jun 2023 00:42:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77374C433EF; Thu, 1 Jun 2023 00:42:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685580125; bh=QkqbhcDF+pePoD2TNskyYwxfYiTvfX92sxcQEnCW/OQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Iq745KawOqer46I4sbFStKnkH553BxrLo/IZbhCWXZ7S4L5zSYWeO8Q0Rg5Bm4rk3 kB0/A9X9I0mxk3O1Wc3wFiM+7GzvyRVmuvYR/BWi4nTc6kGqsZVMCCeUPVDQiOiPsc TLL/eJ+g0AJctxcsP4SMeFIab6k4a1ojYhCGH2PceqDPXrgeVI0abfb0Pc5qNadw2b QdCNPUA2i9rEAwj6zME8FxYJ8boKpMUlsfJDqipm3/3NK0yEYRw+5zEvhqIV/BM5HP qdUsOi0z9GI9Q2KCdu59IbgH/heA9cIOBDTv+JigOBDsC07z/GYz/L38N2SHP9rLpO r12AdJxg9vS2w== Date: Wed, 31 May 2023 17:42:02 -0700 From: Josh Poimboeuf To: Jon Kohler Cc: Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , "Peter Zijlstra (Intel)" , Pawan Gupta , Daniel Sneddon , "kvm @ vger . kernel . org" , LKML , Andrew Cooper Subject: Re: [PATCH] KVM: VMX: remove LFENCE in vmx_spec_ctrl_restore_host() Message-ID: <20230601004202.63yulqs73kuh3ep6@treble> References: <20230531150112.76156-1-jon@nutanix.com> <20230531231820.trrs2uugc24gegj4@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 31, 2023 at 11:58:12PM +0000, Jon Kohler wrote: > > The goal of this barrier_nospec() is to prevent speculative execution > > from bypassing the SPEC_CTRL write (due to misprediction of the > > conditional branch, Spectre v1 style). Otherwise the next indirect > > branch or unbalanced RET could be an attack target. > > > > So any previous LFENCEs before that conditional branch won't help here. > > Ah interesting. Ok, to be clear, thats a guest -> host attack, correct? And such > an attack would not at all be thwarted by the first CALL retire + LFENCE that > was added on commit 2b1299322016 ("x86/speculation: Add RSB VM Exit > protections”)? Right. > Sorry to be long winded, just wanting to triple check because > the aforementioned commit was added slightly after the original one, and I > want to make extra sure that they aren’t solving the same thing. > > If that is indeed the case, does that commit need to be revisited at all? > > Or are we saying that this Intel vulnerability needs *two* LFENCE’s to keep > the host secure? The first LFENCE (FILL_RETURN_BUFFER) forces the CALL to retire so the RSB stuff is guaranteed to take effect before the next unbalanced RET can be speculatively executed. The second LFENCE (vmx_spec_ctrl_restore_host) forces the conditional branch to retire so the SPEC_CTRL write (potential IBRS/eIBRS enablement) is guaranteed to take effect before the next indirect branch and/or unbalanced RET can be speculatively executed. So each LFENCE has a distinct purpose. That said, there are no indirect branches or unbalanced RETs between them. So it should be fine to combine them into a single LFENCE after both. You could for example just remove the first LFENCE. But only for that usage site, i.e. not for other users of FILL_RETURN_BUFFER. Or, remove them both and add an LFENCE in vmx_vmexit() right after the call to vmx_spec_ctrl_restore_host(). That might be clearer. Then it could have a comment describing its dual purposes. -- Josh