Received: by 10.223.185.111 with SMTP id b44csp445682wrg; Fri, 9 Mar 2018 07:35:26 -0800 (PST) X-Google-Smtp-Source: AG47ELtZhaRHbvackcbp/+cIE3bqllSX9iekire3xC8OtXiZNd9Lv8ePK5jvbP6l2UBy6ylhQuVr X-Received: by 10.99.121.5 with SMTP id u5mr24596495pgc.444.1520609725635; Fri, 09 Mar 2018 07:35:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520609725; cv=none; d=google.com; s=arc-20160816; b=gOBVZW9KzarjGlrR1fZ0G1sCwWS5mpCAs4ROTHN4ktP0/cil3yTP/SFdHirvBilhcD YTwYGgdBwvnPzlAXXyOgXjNc/8F4rR6ol+SzFWahWDKtcvZF2nF1yUuW2xFYysOltHPp T0RyGgW0as/FcNcEgjDOMUbSB41Ng9mGjJ/bJOBNXK45sHeaa3yV1J/PrQfuCP+mQvky dzbJsbrYsL81bPmt9+k2v4AX8gGgfHKOhPpasESUVFRK9tl2l2LkOQaQVMXH4pSQK4Dq 3Ebk2CjT2QdQCiCxH0s34E2JaKpxp19i+8152l2jTgzNPfpLYJjDiyg3mD6iRzFgwJ4D 3zag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=MqszzVTXl3lKFxWnKUT1GFCLTqTICtENtPzXFrg7rgc=; b=GLf3QFtGbC8TfYmFOtZ1gEgGXVYclw1Do62PsetjH2Ysutm2CtqL755k8QKK2voYhH SzPnj3w6Vsru4a90JdmWaccQsdsHw/Ic86YNVeNCJl8BKExeTHvEkfl4AP7z65IjkYi5 J1CKWZ1/OWinOIUahErC/qYjfz45JYrJWwatLSM5Qt0+YBWYfpZGD91NTb3Lsj2YgPDR JE1UWEaCwlvbfsydv+Prpuc72Pj5wyZervhpS+ulv8Mc6YsjpepGZLMDp6L2euEnINad s6JaaxOocFg4vXvDktbEkYOGVy+6UTNfjzbcm7GKl6dR2JwYYsPSVA07GmrcjbqkmvzQ 55jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8si854476pgv.699.2018.03.09.07.35.10; Fri, 09 Mar 2018 07:35:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751215AbeCIPeS (ORCPT + 99 others); Fri, 9 Mar 2018 10:34:18 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:45836 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbeCIPeR (ORCPT ); Fri, 9 Mar 2018 10:34:17 -0500 Received: by vps-vb.mhejs.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1euK1n-0003GK-Nl; Fri, 09 Mar 2018 16:33:51 +0100 Subject: Re: x86/retpoline: Fill RSB on context switch for affected CPUs To: Andi Kleen Cc: "Woodhouse, David" , Paul Turner , LKML , Linus Torvalds , Greg Kroah-Hartman , Tim Chen , Dave Hansen , tglx@linutronix.de, Kees Cook , Rik van Riel , Peter Zijlstra , Andy Lutomirski , Jiri Kosina , gnomes@lxorguk.ukuu.org.uk, x86@kernel.org, thomas.lendacky@amd.com, Josh Poimboeuf References: <1515779365-9032-1-git-send-email-dwmw@amazon.co.uk> <20180309151428.GE22087@tassilo.jf.intel.com> From: "Maciej S. Szmigiero" Message-ID: Date: Fri, 9 Mar 2018 16:33:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180309151428.GE22087@tassilo.jf.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.03.2018 16:14, Andi Kleen wrote: >> Shouldn't the RSB filling on context switch also be done on non-IBPB >> CPUs to protect (retpolined) user space tasks from other user space >> tasks? > > The comment is actually incorrect. There's no risk to hit user space > addresses if we have KPTI and NX (which is fairly universal). > > It's mainly needed on Skylake era CPUs. > > Should fix the comment. I'll send a patch. But what about userspace-to-userspace attacks? - the ones that IBPB on context switches currently protects against (at least for high-value, or as implemented currently, non-dumpable, processes)? If understand the issue correctly, high-value user space processes can be protected from other user space processes even on CPUs that lack IBPB as long as they are recompiled with retpolines and there is no danger of RSB entries from one process being used by another one after a context switch. For Skyklake this would not be enough, but there we'll (hopefully) have the IBPB instead. > -Andi > Maciej