linux-kernel - Re: [PATCH v19 00/27] riscv control-flow integrity for usermode

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]

Message-ID: <20250926195224.351862-1-cmirabil@redhat.com>
Date: Fri, 26 Sep 2025 15:52:24 -0400
From: Charles Mirabile <cmirabil@...hat.com>
To: cmirabil@...hat.com
Cc: Liam.Howlett@...cle.com,
	a.hindborg@...nel.org,
	akpm@...ux-foundation.org,
	alex.gaynor@...il.com,
	alexghiti@...osinc.com,
	aliceryhl@...gle.com,
	alistair.francis@....com,
	andybnac@...il.com,
	aou@...s.berkeley.edu,
	arnd@...db.de,
	atishp@...osinc.com,
	bjorn3_gh@...tonmail.com,
	boqun.feng@...il.com,
	bp@...en8.de,
	brauner@...nel.org,
	broonie@...nel.org,
	charlie@...osinc.com,
	cleger@...osinc.com,
	conor+dt@...nel.org,
	conor@...nel.org,
	corbet@....net,
	dave.hansen@...ux.intel.com,
	david@...hat.com,
	debug@...osinc.com,
	devicetree@...r.kernel.org,
	ebiederm@...ssion.com,
	evan@...osinc.com,
	gary@...yguo.net,
	hpa@...or.com,
	jannh@...gle.com,
	jim.shu@...ive.com,
	kees@...nel.org,
	kito.cheng@...ive.com,
	krzk+dt@...nel.org,
	linux-arch@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org,
	linux-riscv@...ts.infradead.org,
	lorenzo.stoakes@...cle.com,
	lossin@...nel.org,
	mingo@...hat.com,
	ojeda@...nel.org,
	oleg@...hat.com,
	palmer@...belt.com,
	paul.walmsley@...ive.com,
	peterz@...radead.org,
	pjw@...nel.org,
	richard.henderson@...aro.org,
	rick.p.edgecombe@...el.com,
	robh@...nel.org,
	rust-for-linux@...r.kernel.org,
	samitolvanen@...gle.com,
	shuah@...nel.org,
	tglx@...utronix.de,
	tmgross@...ch.edu,
	vbabka@...e.cz,
	x86@...nel.org,
	zong.li@...ive.com
Subject: Re: [PATCH v19 00/27] riscv control-flow integrity for usermode

Hi -

Sorry for my previous email, I realized I was mistaken...

On Fri, Sep 26, 2025 at 03:29:19PM -0400, Charles Mirabile wrote:
> Hi - 
> 
> Hoping that I got everything right with git-send-email so that this is
> delivered alright...
> 
> Wanted to jump in to head off a potential talking past one another / 
> miscommunication situation I see here.
> 
> On Wed, Sep 24, 2025 at 08:36:11AM -0600, Paul Walmsley wrote:
> > Hi,
> > 
> > On Thu, 31 Jul 2025, Deepak Gupta wrote:
> > 
> > [ ... ]
> > 
> > > vDSO related Opens (in the flux)
> > > =================================
> > > 
> > > I am listing these opens for laying out plan and what to expect in future
> > > patch sets. And of course for the sake of discussion.
> > > 
> > 
> > [ ... ]
> > 
> > > How many vDSOs
> > > ---------------
> > > Shadow stack instructions are carved out of zimop (may be operations) and if CPU
> > > doesn't implement zimop, they're illegal instructions. Kernel could be running on
> > > a CPU which may or may not implement zimop. And thus kernel will have to carry 2
> > > different vDSOs and expose the appropriate one depending on whether CPU implements
> > > zimop or not.
> > 
> > If we merge this series without this, then when CFI is enabled in the 
> > Kconfig, we'll wind up with a non-portable kernel that won't run on older 
> > hardware.  We go to great lengths to enable kernel binary portability 
> > across the presence or absence of other RISC-V extensions, and I think 
> > these CFI extensions should be no different.
> 
> That is not true, this series does not contain the VDSO changes so it can
> be merged as is.

Oops... no sorry, it looks like it does. See 19/27. I was misled by the
cover letter which said to pick that patch separately. I completely agree
that that needs to not be included if this is to be merged.

> 
> > 
> > So before considering this for merging, I'd like to see at least an 
> > attempt to implement the dual-vDSO approach (or something equivalent) 
> > where the same kernel binary with CFI enabled can run on both pre-Zimop 
> > and post-Zimop hardware, with the existing userspaces that are common 
> > today.
> 
> I agree that when the VDSO patches are submitted for inclusion they should
> be written in a way that avoids limiting the entire kernel to either
> pre-Zimop or post-Zimop hardware based on the config, but I think it
> should be quite possible to perform e.g. runtime patching of the VDSO
> to replace the Zimop instructions with nops if the config is enabled but
> the hardware does not support Zimop.
> 
> However, that concern should not hold up this patch series. Raise it again
> when the VDSO patches are posted.

@Deepak, would it be possible to just resend this without the VDSO patch?

Or to rework as I had alluded to to check for the presense of the extension
and remove the instructions from the VDSO at boot if it is not found?

> 
> > 
> > thanks Deepak,
> > 
> > - Paul
> 
> Best - Charlie
> 

Best - Charlie