On Wed, Feb 12, 2025 at 03:21:48AM +0000, jeffxu@xxxxxxxxxxxx wrote: > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > > The commit message in the first patch contains the full description of > this series. Sorry to nit, but it'd be useful to reproduce in the cover letter too! But this obviously isn't urgent, just be nice when we un-RFC. Thanks for sending as RFC, appreciated, keen to figure out a way forward with this series and this gives us space to discuss. One thing that came up recently with the LWN article (...!) was that rr is also impacted by this [0]. I think with this behind a config flag we're fine (this refers to my 'opt-in' comment in the reply on LWN) as my concerns about this being enabled in a broken way without an explicit kernel configuration are addressed, and actually we do expose a means by which a user can detect if the VDSO for instance is sealed via /proc/$pid/[s]maps. So tools like rr and such can be updated to check for this. I wonder if we ought to try to liaise with the known problematic ones? It'd be nice to update the documentation to have a list of 'known problematic userland software with sealed VDSO' so we make people aware. Hopefully we are acheiving the opt-in nature of the thing here, but it makes me wonder whether we need a prctl() interface to optionally disable even if the system has it enabled as a whole. That way, rr for instance can just turn it off for debugging purposes. To be clear I am not trying to add additional extranous tasks here - my one and only motive is to ensure that the feature works and we address concerns about any possible breakage. And I _want the series to land_ :>) I suspect we're close now. I am tied up with a number of other tasks at the moment so apologies if I take a second to get back to this series, but just wanted to say thanks for addressing my various points, and that I will definitely provide review (it's on the whiteboard, the only true guarantee I will do something :P). I will also come back to your testing series which I owe you review on, which is equally on the same whiteboard... Thanks, Lorenzo [0]:https://lwn.net/Articles/1007984/ > > ------------------ > History: > > V5 > - Remove kernel cmd line (Lorenzo Stoakes) > - Add test info (Lorenzo Stoakes) > - Add threat model info (Lorenzo Stoakes) > - Fix x86 selftest: test_mremap_vdso > - Restrict code change to ARM64/x86-64/UM arch only. > - Add userprocess.h to include seal_system_mapping(). > - Remove sealing vsyscall. > - Split the patch. > > V4: > https://lore.kernel.org/all/20241125202021.3684919-1-jeffxu@xxxxxxxxxx/ > > V3: > https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@xxxxxxxxxx/ > > V2: > https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@xxxxxxxxxx/ > > V1: > https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@xxxxxxxxxx/ > > Jeff Xu (7): > mseal, system mappings: kernel config and header change > selftests: x86: test_mremap_vdso: skip if vdso is msealed > mseal, system mappings: enable x86-64 > mseal, system mappings: enable arm64 > mseal, system mappings: enable uml architecture > mseal, system mappings: uprobe mapping > mseal, system mappings: update mseal.rst > > Documentation/userspace-api/mseal.rst | 5 +++ > arch/arm64/Kconfig | 1 + > arch/arm64/kernel/vdso.c | 23 +++++++---- > arch/um/Kconfig | 1 + > arch/x86/Kconfig | 1 + > arch/x86/entry/vdso/vma.c | 17 ++++++--- > arch/x86/um/vdso/vma.c | 7 +++- > include/linux/userprocess.h | 18 +++++++++ > init/Kconfig | 18 +++++++++ > kernel/events/uprobes.c | 6 ++- > security/Kconfig | 18 +++++++++ > .../testing/selftests/x86/test_mremap_vdso.c | 38 +++++++++++++++++++ > 12 files changed, 137 insertions(+), 16 deletions(-) > create mode 100644 include/linux/userprocess.h > > -- > 2.48.1.502.g6dc24dfdaf-goog >
