From: Mark Rutland <mark.rutland@arm.com>
To: ard.biesheuvel@linaro.org, kernel-hardening@lists.openwall.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: akashi.takahiro@linaro.org, catalin.marinas@arm.com,
dave.martin@arm.com, james.morse@arm.com,
labbott@fedoraproject.org, will.deacon@arm.com,
keescook@chromium.org, Mark Rutland <mark.rutland@arm.com>
Subject: [RFC PATCH 0/6] arm64: alternative VMAP_STACK implementation
Date: Wed, 12 Jul 2017 23:32:57 +0100 [thread overview]
Message-ID: <1499898783-25732-1-git-send-email-mark.rutland@arm.com> (raw)
Hi,
While reviewing Ard's VMAP_STACK series [1], I tried to put together some notes
based on my prior aborted attempts, and tricked myself into turning them into
this series. I suspect we'll want bits of both.
Like Ard's series, this doesn't use EL1t mode, and instead performs a check
early in el1_sync. However, there are a few differences:
* This series frees up SP_EL0, and inverts the current<->percpu relationship
rather than using a GPR for current.
* The out-of-bounds detection *only* considers the SP. Stray accesses below the
SP will be handled as regular faults, unless handling these triggers a stack
overflow.
* There is a dedicated handler for the stack out-of-bounds case (as with x86),
rather than piggy-backing on the usual fault handling code.
* The overflow checks consider IRQ stacks, by keeping track of which stack a
task is currently using. This assumes all stacks are the same size (which
happens to be true today), but we should make that explicit by using common
definitions. Thanks to James Morse for pointing out that we need to handle
this.
Currently the IRQ stacks don't have a guaranteed guard pages, as they're
regular compile-time percpu reservations. We'll want to rework those so that
they have guards.
I haven't audited the backtracing code, but I suspect we'll need to fix up any
stack walking code up so that it understands there are now three possible
stacks that a task may be using, and so that we can walk emergency->irq->task
stack traces.
Otherwise, this series is rough around the seams, and has seen only the most
trivial of testing on a Juno platform (booting 4K and 64K kernels with and
without a deliberate overflow).
I've pushed the series out to my git repo as arm64/vmap-stack [2].
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518368.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/vmap-stack
Mark Rutland (6):
arm64: use tpidr_el1 for current, free sp_el0
arm64: avoid open-coding THREAD_SIZE{,_ORDER}
arm64: pad stacks to PAGE_SIZE for VMAP_STACK
arm64: pass stack base to secondary_start_kernel
arm64: keep track of current stack
arm64: add VMAP_STACK and detect out-of-bounds SP
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/assembler.h | 11 +++++--
arch/arm64/include/asm/current.h | 6 ++--
arch/arm64/include/asm/percpu.h | 15 +++------
arch/arm64/include/asm/thread_info.h | 22 ++++++++++---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/entry.S | 61 ++++++++++++++++++++++++++++++------
arch/arm64/kernel/head.S | 13 ++++++--
arch/arm64/kernel/process.c | 20 +++++-------
arch/arm64/kernel/smp.c | 2 +-
arch/arm64/kernel/traps.c | 21 +++++++++++++
11 files changed, 130 insertions(+), 46 deletions(-)
--
1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/6] arm64: alternative VMAP_STACK implementation
Date: Wed, 12 Jul 2017 23:32:57 +0100 [thread overview]
Message-ID: <1499898783-25732-1-git-send-email-mark.rutland@arm.com> (raw)
Hi,
While reviewing Ard's VMAP_STACK series [1], I tried to put together some notes
based on my prior aborted attempts, and tricked myself into turning them into
this series. I suspect we'll want bits of both.
Like Ard's series, this doesn't use EL1t mode, and instead performs a check
early in el1_sync. However, there are a few differences:
* This series frees up SP_EL0, and inverts the current<->percpu relationship
rather than using a GPR for current.
* The out-of-bounds detection *only* considers the SP. Stray accesses below the
SP will be handled as regular faults, unless handling these triggers a stack
overflow.
* There is a dedicated handler for the stack out-of-bounds case (as with x86),
rather than piggy-backing on the usual fault handling code.
* The overflow checks consider IRQ stacks, by keeping track of which stack a
task is currently using. This assumes all stacks are the same size (which
happens to be true today), but we should make that explicit by using common
definitions. Thanks to James Morse for pointing out that we need to handle
this.
Currently the IRQ stacks don't have a guaranteed guard pages, as they're
regular compile-time percpu reservations. We'll want to rework those so that
they have guards.
I haven't audited the backtracing code, but I suspect we'll need to fix up any
stack walking code up so that it understands there are now three possible
stacks that a task may be using, and so that we can walk emergency->irq->task
stack traces.
Otherwise, this series is rough around the seams, and has seen only the most
trivial of testing on a Juno platform (booting 4K and 64K kernels with and
without a deliberate overflow).
I've pushed the series out to my git repo as arm64/vmap-stack [2].
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518368.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/vmap-stack
Mark Rutland (6):
arm64: use tpidr_el1 for current, free sp_el0
arm64: avoid open-coding THREAD_SIZE{,_ORDER}
arm64: pad stacks to PAGE_SIZE for VMAP_STACK
arm64: pass stack base to secondary_start_kernel
arm64: keep track of current stack
arm64: add VMAP_STACK and detect out-of-bounds SP
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/assembler.h | 11 +++++--
arch/arm64/include/asm/current.h | 6 ++--
arch/arm64/include/asm/percpu.h | 15 +++------
arch/arm64/include/asm/thread_info.h | 22 ++++++++++---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/entry.S | 61 ++++++++++++++++++++++++++++++------
arch/arm64/kernel/head.S | 13 ++++++--
arch/arm64/kernel/process.c | 20 +++++-------
arch/arm64/kernel/smp.c | 2 +-
arch/arm64/kernel/traps.c | 21 +++++++++++++
11 files changed, 130 insertions(+), 46 deletions(-)
--
1.9.1
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: ard.biesheuvel@linaro.org, kernel-hardening@lists.openwall.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: akashi.takahiro@linaro.org, catalin.marinas@arm.com,
dave.martin@arm.com, james.morse@arm.com,
labbott@fedoraproject.org, will.deacon@arm.com,
keescook@chromium.org, Mark Rutland <mark.rutland@arm.com>
Subject: [kernel-hardening] [RFC PATCH 0/6] arm64: alternative VMAP_STACK implementation
Date: Wed, 12 Jul 2017 23:32:57 +0100 [thread overview]
Message-ID: <1499898783-25732-1-git-send-email-mark.rutland@arm.com> (raw)
Hi,
While reviewing Ard's VMAP_STACK series [1], I tried to put together some notes
based on my prior aborted attempts, and tricked myself into turning them into
this series. I suspect we'll want bits of both.
Like Ard's series, this doesn't use EL1t mode, and instead performs a check
early in el1_sync. However, there are a few differences:
* This series frees up SP_EL0, and inverts the current<->percpu relationship
rather than using a GPR for current.
* The out-of-bounds detection *only* considers the SP. Stray accesses below the
SP will be handled as regular faults, unless handling these triggers a stack
overflow.
* There is a dedicated handler for the stack out-of-bounds case (as with x86),
rather than piggy-backing on the usual fault handling code.
* The overflow checks consider IRQ stacks, by keeping track of which stack a
task is currently using. This assumes all stacks are the same size (which
happens to be true today), but we should make that explicit by using common
definitions. Thanks to James Morse for pointing out that we need to handle
this.
Currently the IRQ stacks don't have a guaranteed guard pages, as they're
regular compile-time percpu reservations. We'll want to rework those so that
they have guards.
I haven't audited the backtracing code, but I suspect we'll need to fix up any
stack walking code up so that it understands there are now three possible
stacks that a task may be using, and so that we can walk emergency->irq->task
stack traces.
Otherwise, this series is rough around the seams, and has seen only the most
trivial of testing on a Juno platform (booting 4K and 64K kernels with and
without a deliberate overflow).
I've pushed the series out to my git repo as arm64/vmap-stack [2].
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/518368.html
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/vmap-stack
Mark Rutland (6):
arm64: use tpidr_el1 for current, free sp_el0
arm64: avoid open-coding THREAD_SIZE{,_ORDER}
arm64: pad stacks to PAGE_SIZE for VMAP_STACK
arm64: pass stack base to secondary_start_kernel
arm64: keep track of current stack
arm64: add VMAP_STACK and detect out-of-bounds SP
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/assembler.h | 11 +++++--
arch/arm64/include/asm/current.h | 6 ++--
arch/arm64/include/asm/percpu.h | 15 +++------
arch/arm64/include/asm/thread_info.h | 22 ++++++++++---
arch/arm64/kernel/asm-offsets.c | 4 +++
arch/arm64/kernel/entry.S | 61 ++++++++++++++++++++++++++++++------
arch/arm64/kernel/head.S | 13 ++++++--
arch/arm64/kernel/process.c | 20 +++++-------
arch/arm64/kernel/smp.c | 2 +-
arch/arm64/kernel/traps.c | 21 +++++++++++++
11 files changed, 130 insertions(+), 46 deletions(-)
--
1.9.1
next reply other threads:[~2017-07-12 22:34 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 22:32 Mark Rutland [this message]
2017-07-12 22:32 ` [kernel-hardening] [RFC PATCH 0/6] arm64: alternative VMAP_STACK implementation Mark Rutland
2017-07-12 22:32 ` Mark Rutland
2017-07-12 22:32 ` [RFC PATCH 1/6] arm64: use tpidr_el1 for current, free sp_el0 Mark Rutland
2017-07-12 22:32 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:32 ` Mark Rutland
2017-07-14 1:30 ` Will Deacon
2017-07-14 1:30 ` [kernel-hardening] " Will Deacon
2017-07-14 1:30 ` Will Deacon
2017-07-12 22:32 ` [RFC PATCH 2/6] arm64: avoid open-coding THREAD_SIZE{,_ORDER} Mark Rutland
2017-07-12 22:32 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:32 ` Mark Rutland
2017-07-13 10:18 ` James Morse
2017-07-13 10:18 ` [kernel-hardening] " James Morse
2017-07-13 10:18 ` James Morse
2017-07-13 11:26 ` Mark Rutland
2017-07-13 11:26 ` [kernel-hardening] " Mark Rutland
2017-07-13 11:26 ` Mark Rutland
2017-07-12 22:33 ` [RFC PATCH 3/6] arm64: pad stacks to PAGE_SIZE for VMAP_STACK Mark Rutland
2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:33 ` Mark Rutland
2017-07-12 22:33 ` [RFC PATCH 4/6] arm64: pass stack base to secondary_start_kernel Mark Rutland
2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:33 ` Mark Rutland
2017-07-12 22:33 ` [RFC PATCH 5/6] arm64: keep track of current stack Mark Rutland
2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:33 ` Mark Rutland
2017-07-12 22:33 ` [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP Mark Rutland
2017-07-12 22:33 ` [kernel-hardening] " Mark Rutland
2017-07-12 22:33 ` Mark Rutland
2017-07-13 6:58 ` Ard Biesheuvel
2017-07-13 6:58 ` [kernel-hardening] " Ard Biesheuvel
2017-07-13 6:58 ` Ard Biesheuvel
2017-07-13 10:49 ` Mark Rutland
2017-07-13 10:49 ` [kernel-hardening] " Mark Rutland
2017-07-13 10:49 ` Mark Rutland
2017-07-13 11:49 ` Ard Biesheuvel
2017-07-13 11:49 ` [kernel-hardening] " Ard Biesheuvel
2017-07-13 11:49 ` Ard Biesheuvel
2017-07-13 16:10 ` Mark Rutland
2017-07-13 16:10 ` [kernel-hardening] " Mark Rutland
2017-07-13 16:10 ` Mark Rutland
2017-07-13 17:55 ` [kernel-hardening] " Mark Rutland
2017-07-13 17:55 ` Mark Rutland
2017-07-13 17:55 ` Mark Rutland
2017-07-13 18:28 ` Ard Biesheuvel
2017-07-13 18:28 ` Ard Biesheuvel
2017-07-13 18:28 ` Ard Biesheuvel
2017-07-14 10:32 ` Mark Rutland
2017-07-14 10:32 ` Mark Rutland
2017-07-14 10:32 ` Mark Rutland
2017-07-14 10:48 ` Ard Biesheuvel
2017-07-14 10:48 ` Ard Biesheuvel
2017-07-14 10:48 ` Ard Biesheuvel
2017-07-14 12:27 ` Ard Biesheuvel
2017-07-14 12:27 ` Ard Biesheuvel
2017-07-14 12:27 ` Ard Biesheuvel
2017-07-14 14:06 ` Mark Rutland
2017-07-14 14:06 ` Mark Rutland
2017-07-14 14:06 ` Mark Rutland
2017-07-14 14:14 ` Ard Biesheuvel
2017-07-14 14:14 ` Ard Biesheuvel
2017-07-14 14:14 ` Ard Biesheuvel
2017-07-14 14:39 ` Robin Murphy
2017-07-14 14:39 ` Robin Murphy
2017-07-14 14:39 ` Robin Murphy
2017-07-14 15:03 ` Robin Murphy
2017-07-14 15:03 ` Robin Murphy
2017-07-14 15:03 ` Robin Murphy
2017-07-14 15:15 ` Ard Biesheuvel
2017-07-14 15:15 ` Ard Biesheuvel
2017-07-14 15:15 ` Ard Biesheuvel
2017-07-14 15:25 ` Mark Rutland
2017-07-14 15:25 ` Mark Rutland
2017-07-14 15:25 ` Mark Rutland
2017-07-14 21:27 ` Mark Rutland
2017-07-14 21:27 ` Mark Rutland
2017-07-14 21:27 ` Mark Rutland
2017-07-16 0:03 ` Ard Biesheuvel
2017-07-16 0:03 ` Ard Biesheuvel
2017-07-16 0:03 ` Ard Biesheuvel
2017-07-18 21:53 ` Laura Abbott
2017-07-18 21:53 ` Laura Abbott
2017-07-18 21:53 ` Laura Abbott
2017-07-19 8:08 ` Ard Biesheuvel
2017-07-19 8:08 ` Ard Biesheuvel
2017-07-19 8:08 ` Ard Biesheuvel
2017-07-19 23:32 ` Laura Abbott
2017-07-19 23:32 ` Laura Abbott
2017-07-20 5:35 ` Ard Biesheuvel
2017-07-20 5:35 ` Ard Biesheuvel
2017-07-20 5:35 ` Ard Biesheuvel
2017-07-20 8:36 ` James Morse
2017-07-20 8:36 ` James Morse
2017-07-20 8:36 ` James Morse
2017-07-20 8:56 ` Ard Biesheuvel
2017-07-20 8:56 ` Ard Biesheuvel
2017-07-20 8:56 ` Ard Biesheuvel
2017-07-20 17:30 ` Ard Biesheuvel
2017-07-20 17:30 ` Ard Biesheuvel
2017-07-20 17:30 ` Ard Biesheuvel
2017-07-20 19:10 ` Laura Abbott
2017-07-20 19:10 ` Laura Abbott
2017-07-20 19:10 ` Laura Abbott
2017-07-14 12:52 ` Mark Rutland
2017-07-14 12:52 ` Mark Rutland
2017-07-14 12:52 ` Mark Rutland
2017-07-14 12:55 ` Ard Biesheuvel
2017-07-14 12:55 ` Ard Biesheuvel
2017-07-14 12:55 ` 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=1499898783-25732-1-git-send-email-mark.rutland@arm.com \
--to=mark.rutland@arm.com \
--cc=akashi.takahiro@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=dave.martin@arm.com \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@fedoraproject.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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 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.