From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227nHsLeQiDPUwVsODzRd5i/qydxrnDKn+l/zk+tqWrzpZI78X3g98/zJYCr+nUemhxJSinb ARC-Seal: i=1; a=rsa-sha256; t=1516933432; cv=none; d=google.com; s=arc-20160816; b=CkWOp2p1+yB2OofK+J6g3XjTF5Xh6RjU24e0eoeg/iWmiHLKhQdF0drhibpAfTZJyP 3SQQ27K4dUrm7geTnejoCQptbMjBkYFLEmWH2bocpmQTS9RWh/8jUsENlS+6vE0NBzUP TdOjTxqRV9RXK+PBx2f5ITZc4SDG0pLwB+0m6fLbD8INyko7c/afXzT6cK6ketB8ksgT PA3nlYTdmo/DR/THfh3mdYrAFvpsBaAv2kar3YVa7TzVYVhxOBWRvmSlhxlLPc9xs36O vHRRCnYKzcnXUXxjD37GIEF3jhW85rmkO/5DjCuo4F7jWMXQEQDUmnBaYbYtfTPTb5N3 KP2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:cc:references:to:subject :arc-authentication-results; bh=M1LTYqhr+EbrTHv4AF0WAfHV+V8/3PJg0Pvs1/mQrEg=; b=Owh2xNaCxfWGlns4/Eho4pqfFlOx3tpJOM8SzIJm+XhuCq+Pzd53KwTR8LYrnMJn4D uazYqXPJy0vqShkdo2KFqLG6Lq+9C7rzA724cAYA5i6io/ZqfYalnzDipvIo9eqo2upA GldAEYokcVNAK+LIfIGYq5D0owFeJQ6iA3jKzwOV8tfr/YHTYMzAVpfOliTN8k8L+X28 l7/3h/KDUx1rDxosL49jbCkf1VdKMrhGsMUxTfaEZkZuslrzP+ebi4aMJrT9OTszbGM2 uq2wIPAtMO/QD8nUjawp++wbt6OZG6a65Rg5cRnAW1IVNkMZOMaAH/LePP5O3hHnP+0L k3wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of dave.hansen@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@intel.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of dave.hansen@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=dave.hansen@intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,414,1511856000"; d="scan'208";a="12704227" Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation To: Liran Alon References: <7c0b0879-3448-43e4-8380-4708fc787113@default> Cc: labbott@redhat.com, luto@kernel.org, Janakarajan.Natarajan@amd.com, bp@suse.de, torvalds@linux-foundation.org, asit.k.mallick@intel.com, rkrcmar@redhat.com, karahmed@amazon.de, hpa@zytor.com, jun.nakajima@intel.com, mingo@redhat.com, x86@kernel.org, ashok.raj@intel.com, arjan.van.de.ven@intel.com, tim.c.chen@linux.intel.com, pbonzini@redhat.com, ak@linux.intel.com, linux-kernel@vger.kernel.org, dwmw2@infradead.org, peterz@infradead.org, tglx@linutronix.de, gregkh@linuxfoundation.org, mhiramat@kernel.org, arjan@linux.intel.com, thomas.lendacky@amd.com, dan.j.williams@intel.com, joro@8bytes.org, aarcange@redhat.com, kvm@vger.kernel.org From: Dave Hansen Message-ID: <50c5d627-8975-184b-b50f-4cc02c5816c5@intel.com> Date: Thu, 25 Jan 2018 18:23:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7c0b0879-3448-43e4-8380-4708fc787113@default> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590619990875789427?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/25/2018 06:11 PM, Liran Alon wrote: > It is true that attacker cannot speculate to a kernel-address, but it > doesn't mean it cannot use the leaked kernel-address together with > another unrelated vulnerability to build a reliable exploit. The address doesn't leak if you can't execute there. It's the same reason that we don't worry about speculation to user addresses from the kernel when SMEP is in play.