From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752477AbdKWGvQ (ORCPT ); Thu, 23 Nov 2017 01:51:16 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:43327 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752303AbdKWGvP (ORCPT ); Thu, 23 Nov 2017 01:51:15 -0500 X-Google-Smtp-Source: AGs4zMbXspRDmCLmhIEEH9OQ8rXj5FZ7+xDyCGCul3MTLkNDhbMEh7/INDqoY5iXxG8W1gjrO2vYIA== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) From: Ard Biesheuvel X-Mailer: iPhone Mail (15A432) In-Reply-To: <20171122233738.GA25313@amd> Date: Thu, 23 Nov 2017 06:51:09 +0000 Cc: Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Mark Rutland , Stephen Boyd , Dave Hansen , Kees Cook Message-Id: References: <1510942921-12564-1-git-send-email-will.deacon@arm.com> <20171122161913.GB12684@amd> <20171122223355.GA5877@amd> <20171122233738.GA25313@amd> To: Pavel Machek Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vAN6pL0a006863 > On 22 Nov 2017, at 23:37, Pavel Machek wrote: > > Hi! > >>>>> If I'm willing to do timing attacks to defeat KASLR... what prevents >>>>> me from using CPU caches to do that? >>>>> >>>> >>>> Because it is impossible to get a cache hit on an access to an >>>> unmapped address? >>> >>> 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. >>> >> >> Ah ok. Interesting. >> >> But how does that leak address bits that are covered by the tag? > > Same as leaking any other address bits? Caches are "virtually > indexed", Not on arm64, although I don’t see how that is relevant if you are trying to defeat kaslr. > and tag does not come into play... > Well, I must be missing something then, because I don’t see how knowledge about which userland address shares a cache way with a kernel address can leak anything beyond the bits that make up the index (i.e., which cache way is being shared) > Maybe this explains it? > No not really. It explains how cache timing can be used as a side channel, not how it defeats kaslr. Thanks, Ard.