From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
Date: Wed, 22 Nov 2017 23:36:50 +0100 [thread overview]
Message-ID: <20171122223650.GA6130@amd> (raw)
In-Reply-To: <20171122193713.GL22648@arm.com>
On Wed 2017-11-22 19:37:14, Will Deacon wrote:
> On Wed, Nov 22, 2017 at 05:19:14PM +0100, Pavel Machek wrote:
> > > 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.BECA7D88@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?
>
> Is that a rhetorical question? If not, then I'm probably not the best person
> to answer it. All I'm doing here is protecting against a class of attacks on
> kaslr that make use of the TLB/page-table walker to determine where the
> kernel is mapped.
Yeah. What I'm saying is that I can use cache effects to probe where
kernel is mapped (and what it is doing).
> > There was blackhat talk about exactly that IIRC...
>
> Got a link? I'd be interested to see how the idea works in case there's an
> orthogonal defence against it.
https://www.youtube.com/watch?v=9KsnFWejpQg
(Tell me if it is not the right one).
As of defenses... yes. "maxcpus=1" and flush caches on switch to
usermode will do the trick :-).
Ok, so that was sarcastic. I'm not sure if good defense exists. ARM is
better than i386 because reading time and cache flushing is
priviledged, but...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171122/40227b9d/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
mark.rutland@arm.com, ard.biesheuvel@linaro.org,
sboyd@codeaurora.org, dave.hansen@linux.intel.com,
keescook@chromium.org
Subject: Re: [PATCH 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
Date: Wed, 22 Nov 2017 23:36:50 +0100 [thread overview]
Message-ID: <20171122223650.GA6130@amd> (raw)
In-Reply-To: <20171122193713.GL22648@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]
On Wed 2017-11-22 19:37:14, Will Deacon wrote:
> On Wed, Nov 22, 2017 at 05:19:14PM +0100, Pavel Machek wrote:
> > > 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.BECA7D88@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?
>
> Is that a rhetorical question? If not, then I'm probably not the best person
> to answer it. All I'm doing here is protecting against a class of attacks on
> kaslr that make use of the TLB/page-table walker to determine where the
> kernel is mapped.
Yeah. What I'm saying is that I can use cache effects to probe where
kernel is mapped (and what it is doing).
> > There was blackhat talk about exactly that IIRC...
>
> Got a link? I'd be interested to see how the idea works in case there's an
> orthogonal defence against it.
https://www.youtube.com/watch?v=9KsnFWejpQg
(Tell me if it is not the right one).
As of defenses... yes. "maxcpus=1" and flush caches on switch to
usermode will do the trick :-).
Ok, so that was sarcastic. I'm not sure if good defense exists. ARM is
better than i386 because reading time and cache flushing is
priviledged, but...
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 22:36 UTC|newest]
Thread overview: 90+ 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 ` 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 ` 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 ` 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 ` 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 ` Will Deacon
2017-11-17 18:21 ` [PATCH 05/18] arm64: mm: Rename post_ttbr0_update_workaround Will Deacon
2017-11-17 18:21 ` 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 ` Will Deacon
2017-11-17 18:21 ` [PATCH 07/18] arm64: mm: Allocate ASIDs in pairs Will Deacon
2017-11-17 18:21 ` 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 ` 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 ` 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 ` 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 ` 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 ` 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 ` Will Deacon
2017-11-17 18:21 ` [PATCH 14/18] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code Will Deacon
2017-11-17 18:21 ` Will Deacon
2017-11-18 0:27 ` Stephen Boyd
2017-11-18 0:27 ` Stephen Boyd
2017-11-20 18:05 ` Will Deacon
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 ` 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:21 ` 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 ` Will Deacon
2017-11-17 18:22 ` [PATCH 18/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Will Deacon
2017-11-17 18:22 ` Will Deacon
2017-11-22 16:52 ` Marc Zyngier
2017-11-22 16:52 ` Marc Zyngier
2017-11-22 19:36 ` Will Deacon
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-18 0:19 ` Stephen Boyd
2017-11-20 18:03 ` Will Deacon
2017-11-20 18:03 ` Will Deacon
2017-11-18 15:25 ` Ard Biesheuvel
2017-11-18 15:25 ` Ard Biesheuvel
2017-11-20 18:06 ` Will Deacon
2017-11-20 18:06 ` Will Deacon
2017-11-20 18:20 ` Ard Biesheuvel
2017-11-20 18:20 ` Ard Biesheuvel
2017-11-22 19:37 ` Will Deacon
2017-11-22 19:37 ` Will Deacon
2017-11-20 22:50 ` Laura Abbott
2017-11-20 22:50 ` Laura Abbott
2017-11-22 19:37 ` Will Deacon
2017-11-22 19:37 ` Will Deacon
2017-11-22 16:19 ` Pavel Machek
2017-11-22 16:19 ` Pavel Machek
2017-11-22 19:37 ` Will Deacon
2017-11-22 19:37 ` Will Deacon
2017-11-22 22:36 ` Pavel Machek [this message]
2017-11-22 22:36 ` Pavel Machek
2017-11-22 21:19 ` Ard Biesheuvel
2017-11-22 21:19 ` Ard Biesheuvel
2017-11-22 22:33 ` Pavel Machek
2017-11-22 22:33 ` Pavel Machek
2017-11-22 23:19 ` Ard Biesheuvel
2017-11-22 23:19 ` Ard Biesheuvel
2017-11-22 23:37 ` Pavel Machek
2017-11-22 23:37 ` Pavel Machek
2017-11-23 6:51 ` Ard Biesheuvel
2017-11-23 6:51 ` Ard Biesheuvel
2017-11-23 9:07 ` Pavel Machek
2017-11-23 9:07 ` Pavel Machek
2017-11-23 9:23 ` Ard Biesheuvel
2017-11-23 9:23 ` Ard Biesheuvel
2017-11-23 10:46 ` Pavel Machek
2017-11-23 10:46 ` Pavel Machek
2017-11-23 11:38 ` Ard Biesheuvel
2017-11-23 11:38 ` Ard Biesheuvel
2017-11-23 17:54 ` Pavel Machek
2017-11-23 17:54 ` Pavel Machek
2017-11-23 18:17 ` Ard Biesheuvel
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=20171122223650.GA6130@amd \
--to=pavel@ucw.cz \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.