From: Guo Ren <guoren@kernel.org>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: "Guo Ren" <guoren@linux.alibaba.com>,
"Kees Cook" <keescook@chromium.org>,
"Anup Patel" <anup@brainfault.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-csky@vger.kernel.org, "Atish Patra" <atish.patra@wdc.com>,
"Zong Li" <zong.li@sifive.com>,
"Björn Töpel" <bjorn.topel@gmail.com>,
cooper.qu@linux.alibaba.com,
"Greentime Hu" <greentime.hu@sifive.com>,
linux-riscv <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v4] riscv: Enable per-task stack canaries
Date: Sun, 15 Nov 2020 11:05:52 +0800 [thread overview]
Message-ID: <CAJF2gTT6j3YQJBy6C4Rz-wfYd7r7FkWLV+q1G7NHzBzUQ6iVqw@mail.gmail.com> (raw)
In-Reply-To: <202011131457.63270B286@keescook>
Hi Palmer,
Could you help move the patch into your next-tree with Kees' review added?
On Sat, Nov 14, 2020 at 6:57 AM Kees Cook <keescook@chromium.org> wrote:
>
> On Sun, Oct 18, 2020 at 12:38:17PM +0000, guoren@kernel.org wrote:
> > From: Guo Ren <guoren@linux.alibaba.com>
> >
> > This enables the use of per-task stack canary values if GCC has
> > support for emitting the stack canary reference relative to the
> > value of tp, which holds the task struct pointer in the riscv
> > kernel.
> >
> > After compare arm64 and x86 implementations, seems arm64's is more
> > flexible and readable. The key point is how gcc get the offset of
> > stack_canary from gs/el0_sp.
> >
> > x86: Use a fix offset from gs, not flexible.
> >
> > struct fixed_percpu_data {
> > /*
> > * GCC hardcodes the stack canary as %gs:40. Since the
> > * irq_stack is the object at %gs:0, we reserve the bottom
> > * 48 bytes of the irq stack for the canary.
> > */
> > char gs_base[40]; // :(
> > unsigned long stack_canary;
> > };
> >
> > arm64: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=sysreg
> > -mstack-protector-guard-reg=sp_el0
> > -mstack-protector-guard-offset=xxx
> >
> > riscv: Use -mstack-protector-guard-offset & guard-reg
> > gcc options:
> > -mstack-protector-guard=tls
> > -mstack-protector-guard-reg=tp
> > -mstack-protector-guard-offset=xxx
> >
> > GCC's implementation has been merged:
> > commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
> > Author: Cooper Qu <cooper.qu@linux.alibaba.com>
> > Date: Mon Jul 13 16:15:08 2020 +0800
> >
> > RISC-V: Add support for TLS stack protector canary access
> >
> > In the end, these codes are inserted by gcc before return:
> >
> > * 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
> > * 0xffffffe00020b39a <+124>: xor a5,a5,a4
> > * 0xffffffe00020b39c <+126>: mv a0,s5
> > * 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766>
> > 0xffffffe00020b3a2 <+132>: ld ra,136(sp)
> > 0xffffffe00020b3a4 <+134>: ld s0,128(sp)
> > 0xffffffe00020b3a6 <+136>: ld s1,120(sp)
> > 0xffffffe00020b3a8 <+138>: ld s2,112(sp)
> > 0xffffffe00020b3aa <+140>: ld s3,104(sp)
> > 0xffffffe00020b3ac <+142>: ld s4,96(sp)
> > 0xffffffe00020b3ae <+144>: ld s5,88(sp)
> > 0xffffffe00020b3b0 <+146>: ld s6,80(sp)
> > 0xffffffe00020b3b2 <+148>: ld s7,72(sp)
> > 0xffffffe00020b3b4 <+150>: addi sp,sp,144
> > 0xffffffe00020b3b6 <+152>: ret
> > ...
> > * 0xffffffe00020b61c <+766>: auipc ra,0x7f8
> > * 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
> >
> > Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
>
> Thanks for getting this working! It looks good to me. :)
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
> --
> Kees Cook
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2020-11-15 3:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-18 12:38 [PATCH v4] riscv: Enable per-task stack canaries guoren
2020-11-04 12:05 ` Guo Ren
2020-11-13 22:57 ` Kees Cook
2020-11-15 3:05 ` Guo Ren [this message]
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=CAJF2gTT6j3YQJBy6C4Rz-wfYd7r7FkWLV+q1G7NHzBzUQ6iVqw@mail.gmail.com \
--to=guoren@kernel.org \
--cc=anup@brainfault.org \
--cc=atish.patra@wdc.com \
--cc=bjorn.topel@gmail.com \
--cc=cooper.qu@linux.alibaba.com \
--cc=greentime.hu@sifive.com \
--cc=guoren@linux.alibaba.com \
--cc=keescook@chromium.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmerdabbelt@google.com \
--cc=paul.walmsley@sifive.com \
--cc=zong.li@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).