On Wed, Feb 26, 2025 at 9:43 AM Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote: > > On Wed, Feb 26, 2025 at 09:17:10AM -0800, Jeff Xu wrote: > > On Wed, Feb 26, 2025 at 9:12 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > > > * Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> [250226 00:26]: > > > > On Tue, Feb 25, 2025 at 02:26:50PM -0800, Jeff Xu wrote: > > > > > On Mon, Feb 24, 2025 at 10:20 PM Lorenzo Stoakes > > > > > <lorenzo.stoakes@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Mon, Feb 24, 2025 at 10:52:43PM +0000, jeffxu@xxxxxxxxxxxx wrote: > > > > > > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > > > > > > > > > > > > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on arm64, covering > > > > > > > the vdso, vvar, and compat-mode vectors and sigpage mappings. > > > > > > > > > > > > > > Production release testing passes on Android and Chrome OS. > > > > > > > > > > > > This is pretty limited (yes yes I know android is massive etc. but we must > > > > > > account for all the weird and wonderful arm64 devices out there in context of > > > > > > upstream :) > > > > > > > > > > > > Have you looking through all arm64-code relating to vdso, vvar, compat-mode > > > > > > vectors, sigpage mapping and ensured nothing kernel-side relies upon relocation? > > > > > > Some arches actually seem to want to do this. Pretty sure PPC does... so a bit > > > > > > nervous of that. > > > > > > > > > > > Can you please point out where PPC munmap/mremap the vdso ? > > > > > > > > > > Previously, when you mentioned that, I thought you meant user space in > > > > > PPC, I didn't realize that you meant that kernel code in PPC. I > > > > > tried, but didn't find anything, hence asking. > > > > > > > > Jeff, please stick to replying to review. 'Have you looking through all > > > > arm64-code'. > > > > I checked the kernel code and couldn't find any instances of kernel unmap/remap system mapping in any architecture. But I could be wrong, so I've also included developers from different architectures since V1, and hoping to get some insight. > > > > I ended up doing this myself yesterday and found no issues, as with x86-64. > > > > Thank you for double checking. > > > > I said I'm _pretty sure_ PPC does this. Liam mentioned something about > > > > it. We can discuss it, and I can find specifics if + when you try to add > > > > this to PPC. > > > > > > > > > > PPC allows the vma to be munmapped then detects and falls back to the > > > slower method, iirc. > > > > > Is this code in the kernel or userspace? > > > > If PPC doesn't want to create vdso for all its userspace apps, we > > could instead "don't create" vdso during the execve call. > > > > > > > They were against the removal of the fallback; other archs also have > > > this infrastructure. Really, if we fixed the fallback to work for > > > all platforms then it would probably also remove the possibility of a > > > remap over the VDSO being a problem (if it is today, which still isn't > > > clear?). > > > > > Any past thread/communication about this that I can read ? > > Jeff, I'm sure you don't intend to, but I find it quite disrespectful that you > ignored my feedback here (and elsewhere, regarding you ignoring 4 sets of > feedback). > I'm just interested in the details :), If we know why PPC needs to unmap/remap vdso, then there are additional data points to consider, when we develop pre-process level control for this feature. But sure, we can postpone this. > This? > > https://elixir.bootlin.com/linux/v6.13.4/source/arch/powerpc/kernel/vdso.c#L236 > OK, you meant the failed case ? i.e. when install_special_mappings failed ? That is a case that I haven't considered. It looks like error handling, and I was expecting the install_special_mappings to never fail, maybe I'm wrong here for PPC. > Was [0] a relevant discussion? > Sorry, I'm kind of lost. This link doesn't give a reason why PPC needs to be unmap. If it is due to CRIU or other user space apps, that is not an architecture dependency, maybe a distribution dependency. Anyway, we can postpone this discussion for PPC, I don't mean to make you spend more time responding to me. Please feel free to ignore this one. Thanks. -Jeff > [0]: https://lore.kernel.org/all/lhe2mky6ahlk2jzvvfjyongqiseelyx2uy7sbyuso6jcy3b2dq@7ju6cea62jgk/ > > > > > Thanks > > -Jeff > > > > > > > Thanks, > > > Liam
