linux-kernel - Re: [RFC PATCH 02/12] riscv: add landing pad for asm routines.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Thu, 11 Apr 2024 18:33:33 +0000
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Deepak Gupta <debug@...osinc.com>
Cc: linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev, paul.walmsley@...ive.com, palmer@...belt.com, 
	aou@...s.berkeley.edu, nathan@...nel.org, ndesaulniers@...gle.com, 
	morbo@...gle.com, justinstitt@...gle.com, andy.chiu@...ive.com, 
	hankuan.chen@...ive.com, guoren@...nel.org, greentime.hu@...ive.com, 
	cleger@...osinc.com, apatel@...tanamicro.com, ajones@...tanamicro.com, 
	conor.dooley@...rochip.com, mchitale@...tanamicro.com, 
	dbarboza@...tanamicro.com, waylingii@...il.com, sameo@...osinc.com, 
	alexghiti@...osinc.com, akpm@...ux-foundation.org, shikemeng@...weicloud.com, 
	rppt@...nel.org, charlie@...osinc.com, xiao.w.wang@...el.com, 
	willy@...radead.org, jszhang@...nel.org, leobras@...hat.com, 
	songshuaishuai@...ylab.org, haxel@....de, samuel.holland@...ive.com, 
	namcaov@...il.com, bjorn@...osinc.com, cuiyunhui@...edance.com, 
	wangkefeng.wang@...wei.com, falcon@...ylab.org, viro@...iv.linux.org.uk, 
	bhe@...hat.com, chenjiahao16@...wei.com, hca@...ux.ibm.com, arnd@...db.de, 
	kent.overstreet@...ux.dev, boqun.feng@...il.com, oleg@...hat.com, 
	paulmck@...nel.org, broonie@...nel.org, rick.p.edgecombe@...el.com
Subject: Re: [RFC PATCH 02/12] riscv: add landing pad for asm routines.

On Thu, Apr 11, 2024 at 5:53 PM Deepak Gupta <debug@...osinc.com> wrote:
>
> In principle, I agree it should converge with software based kcfi scheme
> as much as possible. However blocker that I see is `hash` is placed just
> before function. This breaks for code mapped as execute only scenarios.
> And ideally would like to have immediates at callsites instead of loads
> (purely perf reason and not security).

I'm not saying the schemes have to be compatible, just that it would
be great to avoid reinventing type annotations etc. For example, when
you implement the fine-grained variant, you could simply override
SYM_TYPED_ENTRY (defined in include/linux/cfi_types.h) to move
__CFI_TYPE inside the function, and then redefine __CFI_TYPE to emit a
landing pad with the correct label. This allows SYM_TYPED_* in
assembly code to work with both KCFI and fine-grained Zicfilp. For the
coarse-grained variant, your current macros are perfectly fine.

> But yes in next version, I'll take a look and try to converge as much as
> possible.

Great, sounds good!

Sami