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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2393C433E0 for ; Mon, 15 Jun 2020 18:03:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C8197207DD for ; Mon, 15 Jun 2020 18:03:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592244203; bh=+5HFJpJQtbKYKH+dslubvD5LyVXEbC0RC9qH+FG9cVY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=o9lE6f/+2Pfks/7XRsm2peil+8cw9NGvB4/741+sWOWsCkJIdtWbxtB1KzXuVxehg xFoBpVK/lTowYQx8iY0e+zFfKT6bv9gGU4eATALE/KSfLeRRB6ijZ2ryjEIxkNOE/H 9TD9LeKlEh4I5+fWYLs36fgfS0ro5AG/9Cl7/v4s= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729354AbgFOSDX (ORCPT ); Mon, 15 Jun 2020 14:03:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:60530 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728585AbgFOSDW (ORCPT ); Mon, 15 Jun 2020 14:03:22 -0400 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B8503206F1; Mon, 15 Jun 2020 18:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592244202; bh=+5HFJpJQtbKYKH+dslubvD5LyVXEbC0RC9qH+FG9cVY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=2XL2BkabGsAZaqOxZTsw8wR28va4nfRLJQCL8Lj9SQmgqToq48vlwqI+U0/wTBPuG 4PPzbtDAA8zg6YS1c134usrUdB0FnsGIuKVW9Qzl9jsPH2TLHNwCPIs5ibxOvYGXQ1 PPVovoW7SvBHHIz4In6UTM5wmiDoBNZhcj36TmkY= Date: Mon, 15 Jun 2020 14:03:18 -0400 From: Sasha Levin To: gregkh@linuxfoundation.org Cc: asteinhauser@google.com, tglx@linutronix.de, stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP" failed to apply to 4.19-stable tree Message-ID: <20200615180318.GG5492@sasha-vm> References: <159222800515682@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <159222800515682@kroah.com> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Jun 15, 2020 at 03:33:25PM +0200, gregkh@linuxfoundation.org wrote: > >The patch below does not apply to the 4.19-stable tree. >If someone wants it applied there, or to any other stable or longterm >tree, then please email the backport, including the original git commit >id to . > >thanks, > >greg k-h > >------------------ original commit in Linus's tree ------------------ > >>From 21998a351512eba4ed5969006f0c55882d995ada Mon Sep 17 00:00:00 2001 >From: Anthony Steinhauser >Date: Tue, 19 May 2020 06:40:42 -0700 >Subject: [PATCH] x86/speculation: Avoid force-disabling IBPB based on STIBP > and enhanced IBRS. > >When STIBP is unavailable or enhanced IBRS is available, Linux >force-disables the IBPB mitigation of Spectre-BTB even when simultaneous >multithreading is disabled. While attempts to enable IBPB using >prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) fail with >EPERM, the seccomp syscall (or its prctl(PR_SET_SECCOMP, ...) equivalent) >which are used e.g. by Chromium or OpenSSH succeed with no errors but the >application remains silently vulnerable to cross-process Spectre v2 attacks >(classical BTB poisoning). At the same time the SYSFS reporting >(/sys/devices/system/cpu/vulnerabilities/spectre_v2) displays that IBPB is >conditionally enabled when in fact it is unconditionally disabled. > >STIBP is useful only when SMT is enabled. When SMT is disabled and STIBP is >unavailable, it makes no sense to force-disable also IBPB, because IBPB >protects against cross-process Spectre-BTB attacks regardless of the SMT >state. At the same time since missing STIBP was only observed on AMD CPUs, >AMD does not recommend using STIBP, but recommends using IBPB, so disabling >IBPB because of missing STIBP goes directly against AMD's advice: >https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf > >Similarly, enhanced IBRS is designed to protect cross-core BTB poisoning >and BTB-poisoning attacks from user space against kernel (and >BTB-poisoning attacks from guest against hypervisor), it is not designed >to prevent cross-process (or cross-VM) BTB poisoning between processes (or >VMs) running on the same core. Therefore, even with enhanced IBRS it is >necessary to flush the BTB during context-switches, so there is no reason >to force disable IBPB when enhanced IBRS is available. > >Enable the prctl control of IBPB even when STIBP is unavailable or enhanced >IBRS is available. > >Fixes: 7cc765a67d8e ("x86/speculation: Enable prctl mode for spectre_v2_user") >Signed-off-by: Anthony Steinhauser >Signed-off-by: Thomas Gleixner >Cc: stable@vger.kernel.org I took these two additional patches for 4.19-4.4: aa77bfb354c4 ("x86/speculation: Change misspelled STIPB to STIBP") 20c3a2c33e9f ("x86/speculation: Add support for STIBP always-on preferred mode") With tiny massaging on 4.9 and 4.4. -- Thanks, Sasha