From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org,
ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
james.morse@arm.com, keescook@chromium.org,
linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com,
luto@kernel.org, suzuki.poulose@arm.com,
takahiro.akashi@linaro.org, will.deacon@arm.com,
kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [RFC PATCH 0/8] arm64: move thread_info off of the task stack
Date: Wed, 21 Sep 2016 11:31:47 +0100 [thread overview]
Message-ID: <20160921103147.GD18176@leverpostej> (raw)
In-Reply-To: <f954c330-fb58-5f8f-1d66-5bbcd0d9dadb@redhat.com>
On Tue, Sep 20, 2016 at 06:26:54PM -0700, Laura Abbott wrote:
> On 09/15/2016 06:49 AM, Mark Rutland wrote:
> >Building atop of Andy's work on x86 and generic code, these patches move
> >arm64's thread_info off of the stack and into task_struct. This protects
> >thread_info from corruption in the face of stack overflow, and serves as
> >a step towards fully robust stack overflow handling will be addressed by
> >subsequent patches.
> >
> >In contrast to x86, we can't place some critical data such as
> >preempt_count in percpu variables, and we must store these in some
> >per-task location. This, compounded with the way headers are organised
> >conspires to require us to still define our own thread_info. I
> >understand that the longer term plan is to kill off thread_info
> >entirely, hence I'm sending this as an RFC so we can figure out if/how
> >we can achieve that.
> >
> >These patches are based on Andy's x86/vmap_stack branch [1,2], and I've
> >pushed a copy to me arm64/ti-stack-split branch [3,4]. The result of
> >these patches boots happily on platforms within reach of my desk, but
> >has not seen much stressing so far.
>
> FWIW, I used your ti-stack-split branch while running some kernel builds
> and it seems to work well enough. You can take that as a Tested-by or I
> can re-test with a non-RFC version.
Thanks for testing, and many thanks for the offer!
Based on Andy's feedback some core bits are changing, and I'm hoping to
have a non-RFC version out soon once I've fixed up the remaining
fallout. I'll make sure you're Cc'd!
Thanks,
Mark.
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/8] arm64: move thread_info off of the task stack
Date: Wed, 21 Sep 2016 11:31:47 +0100 [thread overview]
Message-ID: <20160921103147.GD18176@leverpostej> (raw)
In-Reply-To: <f954c330-fb58-5f8f-1d66-5bbcd0d9dadb@redhat.com>
On Tue, Sep 20, 2016 at 06:26:54PM -0700, Laura Abbott wrote:
> On 09/15/2016 06:49 AM, Mark Rutland wrote:
> >Building atop of Andy's work on x86 and generic code, these patches move
> >arm64's thread_info off of the stack and into task_struct. This protects
> >thread_info from corruption in the face of stack overflow, and serves as
> >a step towards fully robust stack overflow handling will be addressed by
> >subsequent patches.
> >
> >In contrast to x86, we can't place some critical data such as
> >preempt_count in percpu variables, and we must store these in some
> >per-task location. This, compounded with the way headers are organised
> >conspires to require us to still define our own thread_info. I
> >understand that the longer term plan is to kill off thread_info
> >entirely, hence I'm sending this as an RFC so we can figure out if/how
> >we can achieve that.
> >
> >These patches are based on Andy's x86/vmap_stack branch [1,2], and I've
> >pushed a copy to me arm64/ti-stack-split branch [3,4]. The result of
> >these patches boots happily on platforms within reach of my desk, but
> >has not seen much stressing so far.
>
> FWIW, I used your ti-stack-split branch while running some kernel builds
> and it seems to work well enough. You can take that as a Tested-by or I
> can re-test with a non-RFC version.
Thanks for testing, and many thanks for the offer!
Based on Andy's feedback some core bits are changing, and I'm hoping to
have a non-RFC version out soon once I've fixed up the remaining
fallout. I'll make sure you're Cc'd!
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org,
ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
james.morse@arm.com, keescook@chromium.org,
linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com,
luto@kernel.org, suzuki.poulose@arm.com,
takahiro.akashi@linaro.org, will.deacon@arm.com,
kernel-hardening@lists.openwall.com
Subject: Re: [RFC PATCH 0/8] arm64: move thread_info off of the task stack
Date: Wed, 21 Sep 2016 11:31:47 +0100 [thread overview]
Message-ID: <20160921103147.GD18176@leverpostej> (raw)
In-Reply-To: <f954c330-fb58-5f8f-1d66-5bbcd0d9dadb@redhat.com>
On Tue, Sep 20, 2016 at 06:26:54PM -0700, Laura Abbott wrote:
> On 09/15/2016 06:49 AM, Mark Rutland wrote:
> >Building atop of Andy's work on x86 and generic code, these patches move
> >arm64's thread_info off of the stack and into task_struct. This protects
> >thread_info from corruption in the face of stack overflow, and serves as
> >a step towards fully robust stack overflow handling will be addressed by
> >subsequent patches.
> >
> >In contrast to x86, we can't place some critical data such as
> >preempt_count in percpu variables, and we must store these in some
> >per-task location. This, compounded with the way headers are organised
> >conspires to require us to still define our own thread_info. I
> >understand that the longer term plan is to kill off thread_info
> >entirely, hence I'm sending this as an RFC so we can figure out if/how
> >we can achieve that.
> >
> >These patches are based on Andy's x86/vmap_stack branch [1,2], and I've
> >pushed a copy to me arm64/ti-stack-split branch [3,4]. The result of
> >these patches boots happily on platforms within reach of my desk, but
> >has not seen much stressing so far.
>
> FWIW, I used your ti-stack-split branch while running some kernel builds
> and it seems to work well enough. You can take that as a Tested-by or I
> can re-test with a non-RFC version.
Thanks for testing, and many thanks for the offer!
Based on Andy's feedback some core bits are changing, and I'm hoping to
have a non-RFC version out soon once I've fixed up the remaining
fallout. I'll make sure you're Cc'd!
Thanks,
Mark.
next prev parent reply other threads:[~2016-09-21 10:31 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-15 13:49 [kernel-hardening] [RFC PATCH 0/8] arm64: move thread_info off of the task stack Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 1/8] thread_info: include <current.h> for THREAD_INFO_IN_TASK Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 2/8] thread_info: allow custom in-task thread_info Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 18:37 ` [kernel-hardening] " Andy Lutomirski
2016-09-15 18:37 ` Andy Lutomirski
2016-09-15 18:37 ` Andy Lutomirski
2016-09-16 10:33 ` [kernel-hardening] " Mark Rutland
2016-09-16 10:33 ` Mark Rutland
2016-09-16 10:33 ` Mark Rutland
2016-09-16 15:11 ` [kernel-hardening] " Andy Lutomirski
2016-09-16 15:11 ` Andy Lutomirski
2016-09-16 15:11 ` Andy Lutomirski
2016-09-19 10:44 ` [kernel-hardening] " Mark Rutland
2016-09-19 10:44 ` Mark Rutland
2016-09-19 10:44 ` Mark Rutland
2016-09-21 10:28 ` [kernel-hardening] " Mark Rutland
2016-09-21 10:28 ` Mark Rutland
2016-09-21 10:28 ` Mark Rutland
2016-09-22 22:23 ` [kernel-hardening] " Andy Lutomirski
2016-09-22 22:23 ` Andy Lutomirski
2016-09-22 22:23 ` Andy Lutomirski
2016-09-23 17:31 ` [kernel-hardening] " Mark Rutland
2016-09-23 17:31 ` Mark Rutland
2016-09-23 17:31 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 3/8] arm64: thread_info remove stale items Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 4/8] arm64: asm-offsets: remove unused definitions Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 5/8] arm64: assembler: introduce ldr_this_cpu Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 6/8] arm64: traps: use task_struct instead of thread_info Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 7/8] arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` [kernel-hardening] [RFC PATCH 8/8] arm64: split thread_info from task stack Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-15 13:49 ` Mark Rutland
2016-09-21 1:26 ` [kernel-hardening] Re: [RFC PATCH 0/8] arm64: move thread_info off of the " Laura Abbott
2016-09-21 1:26 ` Laura Abbott
2016-09-21 1:26 ` Laura Abbott
2016-09-21 10:31 ` Mark Rutland [this message]
2016-09-21 10:31 ` Mark Rutland
2016-09-21 10:31 ` 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=20160921103147.GD18176@leverpostej \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=luto@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=takahiro.akashi@linaro.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.