[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba45e69f69851721419b84f1ff8b66a490f92c86.camel@intel.com>
Date: Fri, 9 Feb 2024 20:44:53 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "debug@...osinc.com" <debug@...osinc.com>, "ajones@...tanamicro.com"
<ajones@...tanamicro.com>, "bjorn@...osinc.com" <bjorn@...osinc.com>,
"conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
"broonie@...nel.org" <broonie@...nel.org>, "keescook@...omium.org"
<keescook@...omium.org>, "kito.cheng@...ive.com" <kito.cheng@...ive.com>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>, "palmer@...belt.com"
<palmer@...belt.com>, "alex@...ti.fr" <alex@...ti.fr>,
"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>, "alexghiti@...osinc.com"
<alexghiti@...osinc.com>, "atishp@...shpatra.org" <atishp@...shpatra.org>,
"cleger@...osinc.com" <cleger@...osinc.com>
CC: "josh@...htriplett.org" <josh@...htriplett.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "gerg@...nel.org"
<gerg@...nel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "bhe@...hat.com" <bhe@...hat.com>,
"charlie@...osinc.com" <charlie@...osinc.com>, "david@...hat.com"
<david@...hat.com>, "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
"heiko@...ech.de" <heiko@...ech.de>, "panqinglin2020@...as.ac.cn"
<panqinglin2020@...as.ac.cn>, "mchitale@...tanamicro.com"
<mchitale@...tanamicro.com>, "corbet@....net" <corbet@....net>,
"revest@...omium.org" <revest@...omium.org>, "mason.huo@...rfivetech.com"
<mason.huo@...rfivetech.com>, "ojeda@...nel.org" <ojeda@...nel.org>,
"baruch@...s.co.il" <baruch@...s.co.il>, "waylingii@...il.com"
<waylingii@...il.com>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, "joey.gouly@....com" <joey.gouly@....com>,
"ancientmodern4@...il.com" <ancientmodern4@...il.com>,
"mathis.salmen@...sal.de" <mathis.salmen@...sal.de>, "aou@...s.berkeley.edu"
<aou@...s.berkeley.edu>, "shr@...kernel.io" <shr@...kernel.io>,
"andy.chiu@...ive.com" <andy.chiu@...ive.com>, "shuah@...nel.org"
<shuah@...nel.org>, "arnd@...db.de" <arnd@...db.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"vincent.chen@...ive.com" <vincent.chen@...ive.com>,
"greentime.hu@...ive.com" <greentime.hu@...ive.com>, "oleg@...hat.com"
<oleg@...hat.com>, "willy@...radead.org" <willy@...radead.org>,
"zhangqing@...ngson.cn" <zhangqing@...ngson.cn>, "jhubbard@...dia.com"
<jhubbard@...dia.com>, "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"Wang, Xiao W" <xiao.w.wang@...el.com>, "cuiyunhui@...edance.com"
<cuiyunhui@...edance.com>, "brauner@...nel.org" <brauner@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>, "ruscur@...sell.cc"
<ruscur@...sell.cc>, "shikemeng@...weicloud.com" <shikemeng@...weicloud.com>,
"jszhang@...nel.org" <jszhang@...nel.org>, "jeeheng.sia@...rfivetech.com"
<jeeheng.sia@...rfivetech.com>, "alx@...nel.org" <alx@...nel.org>,
"guoren@...nel.org" <guoren@...nel.org>, "chenjiahao16@...wei.com"
<chenjiahao16@...wei.com>, "omosnace@...hat.com" <omosnace@...hat.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "evan@...osinc.com"
<evan@...osinc.com>, "bgray@...ux.ibm.com" <bgray@...ux.ibm.com>,
"apatel@...tanamicro.com" <apatel@...tanamicro.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [RFC PATCH v1 15/28] riscv/mm: Implement map_shadow_stack()
syscall
On Wed, 2024-01-24 at 22:21 -0800, debug@...osinc.com wrote:
> From: Deepak Gupta <debug@...osinc.com>
>
> As discussed extensively in the changelog for the addition of this
> syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
> existing mmap() and madvise() syscalls do not map entirely well onto
> the
> security requirements for guarded control stacks since they lead to
> windows where memory is allocated but not yet protected or stacks
> which
> are not properly and safely initialised. Instead a new syscall
> map_shadow_stack() has been defined which allocates and initialises a
> shadow stack page.
>
> This patch implements this syscall for riscv. riscv doesn't require
> token
> to be setup by kernel because user mode can do that by itself.
> However to
> provide compatiblity and portability with other architectues, user
> mode can
> specify token set flag.
A lot of this code look very familiar. We'll have to think about at
what point we could pull some of it into the code kernel.
I think if we had an arch write_user_shstk(), most of the code could be
shared here.
Powered by blists - more mailing lists