From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751980AbdKVXhl (ORCPT <rfc822;w@1wt.eu>);
        Wed, 22 Nov 2017 18:37:41 -0500
Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:55907 "EHLO
        atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751525AbdKVXhk (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 22 Nov 2017 18:37:40 -0500
Date: Thu, 23 Nov 2017 00:37:38 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Stephen Boyd <sboyd@codeaurora.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in
 userspace (KAISER)
Message-ID: <20171122233738.GA25313@amd>
References: <1510942921-12564-1-git-send-email-will.deacon@arm.com>
 <20171122161913.GB12684@amd>
 <CAKv+Gu9xw92F_K5XhDwpuSWCSbVJOMGSszuGBkyrhqboLhA-Mw@mail.gmail.com>
 <20171122223355.GA5877@amd>
 <C271F3D3-A849-43F5-AE0A-6997890A3857@linaro.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj"
Content-Disposition: inline
In-Reply-To: <C271F3D3-A849-43F5-AE0A-6997890A3857@linaro.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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

Hi!

> >>> 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?

Same as leaking any other address bits? Caches are "virtually
indexed", and tag does not come into play...

Maybe this explains it?

https://www.youtube.com/watch?v=3D9KsnFWejpQg
									Pavel
--=20
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo=
g.html

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

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

iEYEARECAAYFAloWCkIACgkQMOfwapXb+vL32gCgtv3GUCen+rFexYgBQs2xNxUN
6LsAnjmVQd6SmnL2j/4RGxhuBPokM200
=smt3
-----END PGP SIGNATURE-----

--9amGYk9869ThD9tj--