From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752724AbdKWJHy (ORCPT ); Thu, 23 Nov 2017 04:07:54 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:40628 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751632AbdKWJHt (ORCPT ); Thu, 23 Nov 2017 04:07:49 -0500 Date: Thu, 23 Nov 2017 10:07:47 +0100 From: Pavel Machek To: Ard Biesheuvel Cc: Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Mark Rutland , Stephen Boyd , Dave Hansen , Kees Cook Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) Message-ID: <20171123090747.GA6948@amd> References: <1510942921-12564-1-git-send-email-will.deacon@arm.com> <20171122161913.GB12684@amd> <20171122223355.GA5877@amd> <20171122233738.GA25313@amd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" 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 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > On 22 Nov 2017, at 23:37, Pavel Machek wrote: > >=20 > > Hi! > >=20 > >>>>> If I'm willing to do timing attacks to defeat KASLR... what prevents > >>>>> me from using CPU caches to do that? > >>>>>=20 > >>>>=20 > >>>> Because it is impossible to get a cache hit on an access to an > >>>> unmapped address? > >>>=20 > >>> Um, no, I don't need to be able to directly access kernel addresses. I > >>> just put some data in _same place in cache where kernel data would > >>> go_, then do syscall and look if my data are still cached. Caches > >>> don't have infinite associativity. > >>>=20 > >>=20 > >> Ah ok. Interesting. > >>=20 > >> But how does that leak address bits that are covered by the tag? > >=20 > > Same as leaking any other address bits? Caches are "virtually > > indexed", >=20 > Not on arm64, although I don=E2=80=99t see how that is relevant if you ar= e trying to defeat kaslr. >=20 > > and tag does not come into play... > >=20 >=20 > Well, I must be missing something then, because I don=E2=80=99t see how k= nowledge about which userland address shares a cache way with a kernel addr= ess can leak anything beyond the bits that make up the index (i.e., which c= ache way is being shared) >=20 Well, KASLR is about keeping bits of kernel virtual address secret =66rom userland. Leaking them through cache sidechannel means KASLR is defeated. > > Maybe this explains it? > >=20 >=20 > No not really. It explains how cache timing can be used as a side channel= , not how it defeats kaslr. Ok, look at this one: https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Ad= dress-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf You can use timing instead of TSX, right? Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAloWj+MACgkQMOfwapXb+vKSugCfSN2fwXXiPkOZ4DsdN6CGQJS8 IUkAnRu8Bfs05c0IZvojCF7IqoOWp+87 =EZCo -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G--