Date: Thu, 4 Jan 2018 14:32:14 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Andi Kleen <andi@firstfloor.org>, tglx@linutronix.de,
        torvalds@linux-foundation.org, gregkh@linux-foundation.org,
        linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com
Subject: Re: Avoid speculative indirect calls in kernel
Message-ID: <20180104133214.GA2220@amd>
References: <20180104020019.1173-1-andi@firstfloor.org>
 <20180104114917.GC1702@amd>
 <20180104120914.322fa95e@alans-desktop>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <20180104120914.322fa95e@alans-desktop>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org


--YiEDa0DAkWCtVeE4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu 2018-01-04 12:09:14, Alan Cox wrote:
> On Thu, 4 Jan 2018 12:49:17 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
>=20
> > Hi!
> >=20
> > > This is a fix for Variant 2 in=20
> > > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-mem=
ory-with-side.html
> > >=20
> > > Any speculative indirect calls in the kernel can be tricked=20
> > > to execute any kernel code, which may allow side channel
> > > attacks that can leak arbitrary kernel data. =20
> >=20
> > Ok.
> >=20
> > > So we want to avoid speculative indirect calls in the kernel.
> > >=20
> > > There's a special code sequence called a retpoline that can
> > > do indirect calls without speculation. We use a new compiler
> > > option -mindirect-branch=3Dthunk-extern (gcc patch will be released
> > > separately) to recompile the kernel with this new sequence. =20
> >=20
> > So... this "retpoline" code is quite tricky; I guess it does the right
> > on recent Intel CPUs. Does it also do the right thing on all the AMD,
> > Cyrix, ... variants?
> >=20
> > Is it neccessary on all the CPUs? I guess 486 does not need this?
>=20
> It's architecturally valid x86 code so it should work on any x86-32
> processor.
>=20
> You are correct older processors and some of the newer ones don't need
> it. AMD and VIA I don't know about but for Intel we can probably avoid it
> on older Atom, on Quark, and the really old CPUs nobody actually runs any
> more.

Ok. I guess I'd like to see comment in file explaining that.

> That's all an optimization once we have correctness.

Well, correctness first sounds as a good idea. OTOH for Spectre
problem, seems like a fix would be microcode update to flush branch
predictor caches on priviledge and context switches. That should make
it impractical to exploit for all the systems, not just latest Linux,
compiled by lastest Gcc, right?
									Pavel
--=20
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo=
g.html

--YiEDa0DAkWCtVeE4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlpOLN4ACgkQMOfwapXb+vIr+wCggB/Ch18ROKlq5PPer6wTbdEu
Y5QAoISq5cIrQz0BmCh3YbONXNkjaYUh
=5vj4
-----END PGP SIGNATURE-----

--YiEDa0DAkWCtVeE4--