> On 22 Nov 2017, at 22:33, Pavel Machek <pa...@ucw.cz> wrote: > >> On Wed 2017-11-22 21:19:28, Ard Biesheuvel wrote: >>> On 22 November 2017 at 16:19, Pavel Machek <pa...@ucw.cz> wrote: >>> Hi! >>> >>>> This patch series implements something along the lines of KAISER for arm64: >>>> >>>> https://gruss.cc/files/kaiser.pdf >>>> >>>> although I wrote this from scratch because the paper has some funny >>>> assumptions about how the architecture works. There is a patch series >>>> in review for x86, which follows a similar approach: >>>> >>>> http://lkml.kernel.org/r/<20171110193058.beca7...@viggo.jf.intel.com> >>>> >>>> and the topic was recently covered by LWN (currently subscriber-only): >>>> >>>> https://lwn.net/Articles/738975/ >>>> >>>> The basic idea is that transitions to and from userspace are proxied >>>> through a trampoline page which is mapped into a separate page table and >>>> can switch the full kernel mapping in and out on exception entry and >>>> exit respectively. This is a valuable defence against various KASLR and >>>> timing attacks, particularly as the trampoline page is at a fixed virtual >>>> address and therefore the kernel text can be randomized >>>> independently. >>> >>> 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?
