linux-kernel - Re: [RFC PATCH v1 08/28] mm: Define VM_SHADOW

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a6f3ccf5-26a0-45f1-adaa-56a8df569548@redhat.com>
Date: Thu, 25 Jan 2024 09:17:01 +0100
From: David Hildenbrand <david@...hat.com>
To: debug@...osinc.com, rick.p.edgecombe@...el.com, broonie@...nel.org,
 Szabolcs.Nagy@....com, kito.cheng@...ive.com, keescook@...omium.org,
 ajones@...tanamicro.com, paul.walmsley@...ive.com, palmer@...belt.com,
 conor.dooley@...rochip.com, cleger@...osinc.com, atishp@...shpatra.org,
 alex@...ti.fr, bjorn@...osinc.com, alexghiti@...osinc.com
Cc: corbet@....net, aou@...s.berkeley.edu, oleg@...hat.com,
 akpm@...ux-foundation.org, arnd@...db.de, ebiederm@...ssion.com,
 shuah@...nel.org, brauner@...nel.org, guoren@...nel.org,
 samitolvanen@...gle.com, evan@...osinc.com, xiao.w.wang@...el.com,
 apatel@...tanamicro.com, mchitale@...tanamicro.com, waylingii@...il.com,
 greentime.hu@...ive.com, heiko@...ech.de, jszhang@...nel.org,
 shikemeng@...weicloud.com, charlie@...osinc.com, panqinglin2020@...as.ac.cn,
 willy@...radead.org, vincent.chen@...ive.com, andy.chiu@...ive.com,
 gerg@...nel.org, jeeheng.sia@...rfivetech.com, mason.huo@...rfivetech.com,
 ancientmodern4@...il.com, mathis.salmen@...sal.de, cuiyunhui@...edance.com,
 bhe@...hat.com, chenjiahao16@...wei.com, ruscur@...sell.cc,
 bgray@...ux.ibm.com, alx@...nel.org, baruch@...s.co.il,
 zhangqing@...ngson.cn, catalin.marinas@....com, revest@...omium.org,
 josh@...htriplett.org, joey.gouly@....com, shr@...kernel.io,
 omosnace@...hat.com, ojeda@...nel.org, jhubbard@...dia.com,
 linux-doc@...r.kernel.org, linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-arch@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [RFC PATCH v1 08/28] mm: Define VM_SHADOW_STACK for RISC-V

On 25.01.24 07:21, debug@...osinc.com wrote:
> From: Deepak Gupta <debug@...osinc.com>
> 
> VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma.
> 
> x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only.
> arm64 follows same path
> https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e55deaa4dd@kernel.org/#r
> 
> On RISC-V, write-only page table encodings are shadow stack pages. This patch
> re-defines VM_WRITE only to be VM_SHADOW_STACK.
> 
> Next set of patches will set guard rail that no other mm flow can set VM_WRITE
> only in vma except when specifically creating shadow stack.
> 
> Signed-off-by: Deepak Gupta <debug@...osinc.com>
> ---
>   include/linux/mm.h | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 418d26608ece..dfe0e8118669 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -352,7 +352,19 @@ extern unsigned int kobjsize(const void *objp);
>    * for more details on the guard size.
>    */
>   # define VM_SHADOW_STACK	VM_HIGH_ARCH_5
> -#else
> +#endif
> +
> +#ifdef CONFIG_RISCV_USER_CFI
> +/*
> + * On RISC-V pte encodings for shadow stack is R=0, W=1, X=0 and thus RISCV
> + * choosing to use similar mechanism on vm_flags where VM_WRITE only means
> + * VM_SHADOW_STACK. RISCV as well doesn't support VM_SHADOW_STACK to be set
> + * with VM_SHARED.
> + */
> +#define VM_SHADOW_STACK	VM_WRITE
> +#endif
> +
> +#ifndef VM_SHADOW_STACK
>   # define VM_SHADOW_STACK	VM_NONE
>   #endif
>   

That just screams for trouble. Can we find a less hacky way, please?

Maybe just start with 64bit support only and do it like the other archs. 
No need to be special.

When wanting to support 32bit, we'll just finally clean up this high 
flag mess and allow for more vm flags on 32bit as well.

-- 
Cheers,

David / dhildenb