[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171122233738.GA25313@amd>
Date: Thu, 23 Nov 2017 00:37:38 +0100
From: Pavel Machek <pavel@....cz>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Will Deacon <will.deacon@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Stephen Boyd <sboyd@...eaurora.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in
userspace (KAISER)
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", and tag does not come into play...
Maybe this explains it?
https://www.youtube.com/watch?v=9KsnFWejpQg
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists