From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x22430DQGUSEnmw94DW46/qL5xjP0RwNsI3Z+AfVedVuXtu0uAyocj+OUNmUDngGsYrYZP8kd ARC-Seal: i=1; a=rsa-sha256; t=1516933196; cv=none; d=google.com; s=arc-20160816; b=TWnFL/7fglHHzJJcGQ600ZdBmIvJqfejtZW9Q121hk2WDASldj4S8UUwBBJyc/i1br Gbl0j5Ve51bXtK5MgRi7uS+qmDJczkNYwlIlwSWOLy7USr7l9h/a8AbIqL6FTeQZPESw VeIRklAqKqoYl2uvA1X2yj93qkF8TZdstBxdxaqRcM26dzq9Aqf/+3CmP0eo9OnEdYf4 RwJNYfyBpcQernnbC7GuBWtdz6cnq9b3U8kxJboPwsWKBDhPJ1UdwdvXBjYPGfdL6cfO V5Ju+qN43jmoBHyAS0F6wcSFTHeYCLjm9gZ+77NhvOn1dYXMC0LhTxt9zPJv75cvF7s1 GgVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-disposition:content-transfer-encoding:subject:cc:to:from :date:message-id:mime-version:dkim-signature :arc-authentication-results; bh=ZqumEnDhIJITuIqMFv6t//MfAVdPXhcH2HzJo8zrBpM=; b=pEzdgIKeqGGI3EY/WH2RTcGGbmEU1SkWjvF3OdSIYAH8/0jkMD5726rzASeQjyNhlf 5jSAZoEtosoZHp9VwPgJ73dJ85kNOdXA3A//WbceqI3LYyjzUSlafoewndcC8kA61hT0 ugBOsa1xOGqDFj01E1yK0FZ2dxoduIM0jme44k/HJa1z8IedLcv01p/drCI88ydgXzVO QcBpqjoJDiSEXYhyCcbfAEfM0mDK5P3UVBEWrv/eHC/dfeeflCVv5srXY0HCi81Wtj3Q fYuFitk2xgyIARPC6UZ042Xw2IVx0Pr+GkaLZwWGmzaKZR8ykC2eR2eNhQnXwMJ/U96w NaLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=gAa19aGU; spf=pass (google.com: domain of liran.alon@oracle.com designates 156.151.31.85 as permitted sender) smtp.mailfrom=liran.alon@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=gAa19aGU; spf=pass (google.com: domain of liran.alon@oracle.com designates 156.151.31.85 as permitted sender) smtp.mailfrom=liran.alon@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com MIME-Version: 1.0 Message-ID: <7c0b0879-3448-43e4-8380-4708fc787113@default> Date: Thu, 25 Jan 2018 18:11:42 -0800 (PST) From: Liran Alon To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8785 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=607 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801260026 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590619742917116038?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: ----- dave.hansen@intel.com wrote: > On 01/23/2018 03:13 AM, Liran Alon wrote: > > Therefore, breaking KASLR. In order to handle this, every exit from > > kernel-mode to user-mode should stuff RSB. In addition, this > stuffing > > of RSB may need to be done from a fixed address to avoid leaking > the > > address of the RSB stuffing itself. >=20 > With PTI alone in place, I don't see how userspace could do anything > with this information. Even if userspace started to speculate to a > kernel address, there is nothing at the kernel address to execute: no > TLB entry, no PTE to load, nothing. >=20 > You probably have a valid point about host->guest, though. I see it differently. 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 unrel= ated vulnerability to build a reliable exploit. Security is built in layers. The purpose of KASLR is to break the reliablity of an exploit which relies = on vulnerability primitives such as: memory-corruption of a kernel-address,= hijack kernel control-flow to a kernel-address or even just read a kernel-= address. In modern exploitation, it is common to chain multiple different v= ulnerabilities in order to build a reliable exploit. Therefore, leaking a k= ernel-address could be exactly the missing primitive to complete a vulnerab= ility-chain of a reliable exploit. I don't see a big difference between leaking a kernel-address from user-mod= e vs. leaking a hypervisor-address from guest. They are both useful just as= a primitive which is part of an exploit chain. One could argue though, that currently KASLR is fundementally broken and th= erefore should not be considered a security boundary anymore. This argument= could be legit as there were some well-known techniques that could break K= ASLR before KPTI patch-set was introduced (e.g. Timing memory accesses to k= ernel-addresses and messure reliably by leveraging TSX). Another well-known= argument against KASLR is that it is a non-deterministic mitigation which = some argue is not good enough. However, I think that if we decide KASLR is = not a security boundary anymore, it should be made loud and clear. In general, I think there are some info-leak vulnerabilities in our current= mitigation plan which doesn't seem to be addressed. I will be glad if we c= ould address them clearly. These are all the open issues as I see them: 1) Because IBRS doesn't restrict low prediction-mode code from using BTB of= high prediction-mode code, It is possible to info-leak addresses from high= prediction-mode code to low prediciton-mode code. This is the KASLR breakage discussed above. Again, could be ignored if we d= iscard KASLR as a security boundary. 2) Both IBRS & retpoline don't prevent use of BHB of high prediction-mode c= ode from being used by low prediction-mode code. Therefore, low prediction-= mode code could deduce the conditional branches taken by high prediction-mo= de code. 3) Similar leak to (1) exists from the fact that RSB entries of high predic= tion-mode code could be leaked by low prediction-mode code which may reveal= kernel-addresses. Again, we could decide that this isn't a security bounda= ry. An alternative to solve this could be to just stuff RSB from a fixed ad= dress between prediction-mode transitions. -Liran P.S: It seems to me that all these issues could be resolved completely at hardwa= re in future CPUs if BTB/BHB/RSB entries were tagged with prediction-mode (= or similar metadata). It will be nice if Intel/AMD could share if that is t= he planned long-term solution instead of IBRS-all-the-time.