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)
Date: Thu, 23 Nov 2017 00:37:38 +0100 [thread overview]
Message-ID: <20171122233738.GA25313@amd> (raw)
In-Reply-To: <C271F3D3-A849-43F5-AE0A-6997890A3857@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-11-22 23:37 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 18:21 [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) Will Deacon
2017-11-17 18:21 ` [PATCH 01/18] arm64: mm: Use non-global mappings for kernel space Will Deacon
2017-11-17 18:21 ` [PATCH 02/18] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN Will Deacon
2017-11-17 18:21 ` [PATCH 03/18] arm64: mm: Move ASID from TTBR0 to TTBR1 Will Deacon
2017-11-17 18:21 ` [PATCH 04/18] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 Will Deacon
2017-11-17 18:21 ` [PATCH 05/18] arm64: mm: Rename post_ttbr0_update_workaround Will Deacon
2017-11-17 18:21 ` [PATCH 06/18] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN Will Deacon
2017-11-17 18:21 ` [PATCH 07/18] arm64: mm: Allocate ASIDs in pairs Will Deacon
2017-11-17 18:21 ` [PATCH 08/18] arm64: mm: Add arm64_kernel_mapped_at_el0 helper using static key Will Deacon
2017-11-17 18:21 ` [PATCH 09/18] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI Will Deacon
2017-11-17 18:21 ` [PATCH 10/18] arm64: entry: Add exception trampoline page for exceptions from EL0 Will Deacon
2017-11-17 18:21 ` [PATCH 11/18] arm64: mm: Map entry trampoline into trampoline and kernel page tables Will Deacon
2017-11-17 18:21 ` [PATCH 12/18] arm64: entry: Explicitly pass exception level to kernel_ventry macro Will Deacon
2017-11-17 18:21 ` [PATCH 13/18] arm64: entry: Hook up entry trampoline to exception vectors Will Deacon
2017-11-17 18:21 ` [PATCH 14/18] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code Will Deacon
2017-11-18 0:27 ` Stephen Boyd
2017-11-20 18:05 ` Will Deacon
2017-11-17 18:21 ` [PATCH 15/18] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks Will Deacon
2017-11-17 18:21 ` [PATCH 16/18] arm64: entry: Add fake CPU feature for mapping the kernel at EL0 Will Deacon
2017-11-17 18:22 ` [PATCH 17/18] arm64: makefile: Ensure TEXT_OFFSET doesn't overlap with trampoline Will Deacon
2017-11-17 18:22 ` [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Will Deacon
2017-11-22 16:52 ` Marc Zyngier
2017-11-22 19:36 ` Will Deacon
2017-11-18 0:19 ` [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER) Stephen Boyd
2017-11-20 18:03 ` Will Deacon
2017-11-18 15:25 ` Ard Biesheuvel
2017-11-20 18:06 ` Will Deacon
2017-11-20 18:20 ` Ard Biesheuvel
2017-11-22 19:37 ` Will Deacon
2017-11-20 22:50 ` Laura Abbott
2017-11-22 19:37 ` Will Deacon
2017-11-22 16:19 ` Pavel Machek
2017-11-22 19:37 ` Will Deacon
2017-11-22 22:36 ` Pavel Machek
2017-11-22 21:19 ` Ard Biesheuvel
2017-11-22 22:33 ` Pavel Machek
2017-11-22 23:19 ` Ard Biesheuvel
2017-11-22 23:37 ` Pavel Machek [this message]
2017-11-23 6:51 ` Ard Biesheuvel
2017-11-23 9:07 ` Pavel Machek
2017-11-23 9:23 ` Ard Biesheuvel
2017-11-23 10:46 ` Pavel Machek
2017-11-23 11:38 ` Ard Biesheuvel
2017-11-23 17:54 ` Pavel Machek
2017-11-23 18:17 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171122233738.GA25313@amd \
--to=pavel@ucw.cz \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=sboyd@codeaurora.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).