From: Mark Rutland <mark.rutland@arm.com> To: Dan Li <ashimida@linux.alibaba.com> Cc: catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Laura Abbott <labbott@kernel.org> Subject: Re: [PATCH] [RFC]arm64:Mark __stack_chk_guard as __ro_after_init Date: Tue, 14 Sep 2021 11:17:09 +0100 [thread overview] Message-ID: <20210914101709.GA29127@C02TD0UTHF1T.local> (raw) In-Reply-To: <1631612642-102881-1-git-send-email-ashimida@linux.alibaba.com> On Tue, Sep 14, 2021 at 05:44:02PM +0800, Dan Li wrote: > __stack_chk_guard is setup once while init stage and never changed > after that. > > Although the modification of this variable at runtime will usually > cause the kernel to crash (so dose the attacker), it should be marked > as _ro_after_init, and it should not affect performance if it is > placed in the ro_after_init section. > > This should also be the case on the ARM platform, or am I missing > something? > > Signed-off-by: Dan Li <ashimida@linux.alibaba.com> FWIW, this makes sense to me: Acked-by: Mark Rutland <mark.rutland@arm.com> Looking at the history, this was added to arm64 in commit: c0c264ae5112d1cd ("arm64: Add CONFIG_CC_STACKPROTECTOR") ... whereas __ro_after_init was introduced around 2 years later in commit: c74ba8b3480da6dd ("arch: Introduce post-init read-only memory") ... so we weren't deliberately avoiding __ro_after_init, and there are probably a significant number of other variables we could apply it to. Mark. > --- > arch/arm64/kernel/process.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index c8989b9..c858b85 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -60,7 +60,7 @@ > > #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK) > #include <linux/stackprotector.h> > -unsigned long __stack_chk_guard __read_mostly; > +unsigned long __stack_chk_guard __ro_after_init; > EXPORT_SYMBOL(__stack_chk_guard); > #endif > > -- > 2.7.4 >
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Dan Li <ashimida@linux.alibaba.com> Cc: catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Laura Abbott <labbott@kernel.org> Subject: Re: [PATCH] [RFC]arm64:Mark __stack_chk_guard as __ro_after_init Date: Tue, 14 Sep 2021 11:17:09 +0100 [thread overview] Message-ID: <20210914101709.GA29127@C02TD0UTHF1T.local> (raw) In-Reply-To: <1631612642-102881-1-git-send-email-ashimida@linux.alibaba.com> On Tue, Sep 14, 2021 at 05:44:02PM +0800, Dan Li wrote: > __stack_chk_guard is setup once while init stage and never changed > after that. > > Although the modification of this variable at runtime will usually > cause the kernel to crash (so dose the attacker), it should be marked > as _ro_after_init, and it should not affect performance if it is > placed in the ro_after_init section. > > This should also be the case on the ARM platform, or am I missing > something? > > Signed-off-by: Dan Li <ashimida@linux.alibaba.com> FWIW, this makes sense to me: Acked-by: Mark Rutland <mark.rutland@arm.com> Looking at the history, this was added to arm64 in commit: c0c264ae5112d1cd ("arm64: Add CONFIG_CC_STACKPROTECTOR") ... whereas __ro_after_init was introduced around 2 years later in commit: c74ba8b3480da6dd ("arch: Introduce post-init read-only memory") ... so we weren't deliberately avoiding __ro_after_init, and there are probably a significant number of other variables we could apply it to. Mark. > --- > arch/arm64/kernel/process.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index c8989b9..c858b85 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -60,7 +60,7 @@ > > #if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK) > #include <linux/stackprotector.h> > -unsigned long __stack_chk_guard __read_mostly; > +unsigned long __stack_chk_guard __ro_after_init; > EXPORT_SYMBOL(__stack_chk_guard); > #endif > > -- > 2.7.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-14 10:17 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-14 9:44 [PATCH] [RFC]arm64:Mark __stack_chk_guard as __ro_after_init Dan Li 2021-09-14 9:44 ` Dan Li 2021-09-14 9:58 ` Russell King (Oracle) 2021-09-14 9:58 ` Russell King (Oracle) 2021-09-14 10:17 ` Mark Rutland [this message] 2021-09-14 10:17 ` Mark Rutland 2021-09-15 1:57 ` ashimida 2021-09-15 1:57 ` ashimida 2021-09-15 9:19 ` Mark Rutland 2021-09-15 9:19 ` Mark Rutland 2021-09-15 9:35 ` Dan Li 2021-09-15 9:35 ` Dan Li 2021-09-16 17:08 ` Catalin Marinas 2021-09-16 17:08 ` Catalin Marinas
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=20210914101709.GA29127@C02TD0UTHF1T.local \ --to=mark.rutland@arm.com \ --cc=ashimida@linux.alibaba.com \ --cc=catalin.marinas@arm.com \ --cc=labbott@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=will@kernel.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: linkBe 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.