Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752751AbeADT0y (ORCPT + 1 other); Thu, 4 Jan 2018 14:26:54 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:42996 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990AbeADT0w (ORCPT ); Thu, 4 Jan 2018 14:26:52 -0500 Date: Thu, 4 Jan 2018 20:26:49 +0100 From: Pavel Machek To: Dan Williams Cc: Julia Lawall , Alan Cox , Linus Torvalds , Linux Kernel Mailing List , Mark Rutland , linux-arch@vger.kernel.org, Peter Zijlstra , Greg KH , Thomas Gleixner , Elena Reshetova , Alan Cox , Dan Carpenter Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier Message-ID: <20180104192648.GA10427@amd> References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >> > What remains to be seen is if there are other patterns that affect > >> > different processors. > >> > > >> > In the longer term the compiler itself needs to know what is and isn= 't > >> > safe (ie you need to be able to write things like > >> > > >> > void foo(tainted __user int *x) > >> > > >> > and have the compiler figure out what level of speculation it can do= and > >> > (on processors with those features like IA64) when it can and can't = do > >> > various kinds of non-trapping loads. > >> > > >> > >> It would be great if coccinelle and/or smatch could be taught to catch > >> some of these case at least as a first pass "please audit this code > >> block" type of notification. > >> > > > > What should one be looking for. Do you have a typical example? > > >=20 > See "Exploiting Conditional Branch Misprediction" from the paper [1]. >=20 > The typical example is an attacker controlled index used to trigger a > dependent read near a branch. Where an example of "near" from the > paper is "up to 188 simple instructions inserted in the source code > between the =E2=80=98if=E2=80=99 statement and the line accessing array..= =2E". >=20 > if (attacker_controlled_index < bound) > val =3D array[attacker_controlled_index]; > else > return error; >=20 > ...when the cpu speculates that the 'index < bound' branch is taken it > reads index and uses that value to read array[index]. The result of an > 'array' relative read is potentially observable in the cache. You still need (void) array2[val]; after that to get something observable, right? Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlpOf/gACgkQMOfwapXb+vKUyACcDb5n6C009TeXz8Jx0xywDG+/ qowAnR3otDZD619thkpd2jUaL0yAHwNs =wRl0 -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--