From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752674AbdKWJXH (ORCPT ); Thu, 23 Nov 2017 04:23:07 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:38312 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbdKWJXE (ORCPT ); Thu, 23 Nov 2017 04:23:04 -0500 X-Google-Smtp-Source: AGs4zMZasVhuxHe0ZVFbEMn03wgyoP1iB8riSRZ71SVcVHGEn3hmQ5y0hMN6Y4RK7mn93i2szZ7L8IJbZA3jYWiHOyk= MIME-Version: 1.0 In-Reply-To: <20171123090747.GA6948@amd> References: <1510942921-12564-1-git-send-email-will.deacon@arm.com> <20171122161913.GB12684@amd> <20171122223355.GA5877@amd> <20171122233738.GA25313@amd> <20171123090747.GA6948@amd> From: Ard Biesheuvel Date: Thu, 23 Nov 2017 09:23:02 +0000 Message-ID: Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) To: Pavel Machek Cc: Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Mark Rutland , Stephen Boyd , Dave Hansen , Kees Cook Content-Type: text/plain; charset="UTF-8" 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 vAN9NDaO019909 On 23 November 2017 at 09:07, Pavel Machek wrote: > Hi! > >> > 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) >> > > Well, KASLR is about keeping bits of kernel virtual address secret > from userland. Leaking them through cache sidechannel means KASLR is > defeated. > Yes, that is what you claim. But you are not explaining how any of the bits that we do want to keep secret can be discovered by making inferences from which lines in a primed cache were evicted during a syscall. The cache index maps to low order bits. You can use this, e.g., to attack table based AES, because there is only ~4 KB worth of tables, and you are interested in finding out which exact entries of the table were read by the process under attack. You are saying the same approach will help you discover 30 high order bits of a virtual kernel address, by observing the cache evictions in a physically indexed physically tagged cache. How? > >> > Maybe this explains it? >> > >> >> 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-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX-wp.pdf > > You can use timing instead of TSX, right? The TSX attack is TLB based not cache based.