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
