From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/10] arm64: split thread_info from task stack
Date: Fri, 21 Oct 2016 17:20:25 +0100 [thread overview]
Message-ID: <20161021161959.GB17287@leverpostej> (raw)
In-Reply-To: <580A2B3A.7000300@arm.com>
On Fri, Oct 21, 2016 at 03:50:34PM +0100, James Morse wrote:
> Hi Mark,
>
> This looks great, we should definitely do this.
> There are a few things missing from entry.S below:
>
> On 19/10/16 20:10, Mark Rutland wrote:
> > This patch moves arm64's struct thread_info from the task stack into
> > task_struct. This protects thread_info from corruption in the case of
> > stack overflows, and makes its address harder to determine if stack
> > addresses are leaked, making a number of attacks more difficult. Precise
> > detection and handling of overflow is left for subsequent patches.
> >
> > Largely, this involves changing code to store the task_struct in sp_el0,
> > and acquire the thread_info from the task struct (which is the opposite
> > way around to the current code). Both secondary entry and idle are
> > updated to stash the sp and task pointer separately.
> >
> > Userspace clobbers sp_el0, and we can no longer restore this from the
> > stack. Instead, the current task is cached in a per-cpu variable that we
> > can safely access from early assembly as interrupts are disabled (and we
>
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/include/asm/Kbuild | 1 -
> > arch/arm64/include/asm/current.h | 22 ++++++++++++++++++++++
> > arch/arm64/include/asm/smp.h | 1 +
> > arch/arm64/include/asm/thread_info.h | 24 ------------------------
> > arch/arm64/kernel/asm-offsets.c | 1 +
>
> > arch/arm64/kernel/entry.S | 4 ++--
>
> 4? That was too easy...
Far to easy; just looking at kernel_entry there' a glaring error:
.if \el == 0
mrs x21, sp_el0
mov tsk, sp
and tsk, tsk, #~(THREAD_SIZE - 1) // Ensure MDSCR_EL1.SS is clear,
ldr x19, [tsk, #TI_FLAGS] // since we can unmask debug
disable_step_tsk x19, x20 // exceptions when scheduling.
...it's amazing how broken a kernel will boot quite happily.
I've fixed that up locally.
Thanks,
Mark.
next prev parent reply other threads:[~2016-10-21 16:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 19:10 [PATCH 00/10] arm64: move thread_info off of the task stack Mark Rutland
2016-10-19 19:10 ` [PATCH 01/10] arm64: thread_info remove stale items Mark Rutland
2016-10-19 19:10 ` [PATCH 02/10] arm64: asm-offsets: remove unused definitions Mark Rutland
2016-10-19 19:10 ` [PATCH 03/10] arm64: factor out current_stack_pointer Mark Rutland
2016-10-19 19:10 ` [PATCH 04/10] arm64: traps: simplify die() and __die() Mark Rutland
2016-10-19 19:10 ` [PATCH 05/10] arm64: prep stack walkers for THREAD_INFO_IN_TASK Mark Rutland
2016-10-19 19:10 ` [PATCH 06/10] arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx Mark Rutland
2016-10-19 19:10 ` [PATCH 07/10] arm64: smp: prepare for smp_processor_id() rework Mark Rutland
2016-10-19 19:10 ` [PATCH 08/10] arm64: make cpu number a percpu variable Mark Rutland
2016-10-19 19:10 ` [PATCH 09/10] arm64: assembler: introduce ldr_this_cpu Mark Rutland
2016-10-19 19:10 ` [PATCH 10/10] arm64: split thread_info from task stack Mark Rutland
2016-10-21 14:50 ` James Morse
2016-10-21 15:59 ` Mark Rutland
2016-10-21 17:27 ` Mark Rutland
2016-10-21 16:20 ` Mark Rutland [this message]
2016-10-24 17:38 ` [PATCH 00/10] arm64: move thread_info off of the " Laura Abbott
2016-10-24 17:48 ` Mark Rutland
2016-10-24 17:58 ` Laura Abbott
2016-10-24 18:09 ` Mark Rutland
2016-10-24 18:15 ` Mark Rutland
2016-10-24 18:18 ` Kees Cook
2016-10-25 10:05 ` Mark Rutland
2016-10-26 0:46 ` Laura Abbott
2016-10-26 9:55 ` Mark Rutland
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=20161021161959.GB17287@leverpostej \
--to=mark.rutland@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox