On Fri, Feb 28, 2025 at 09:24:11AM -0800, Jeff Xu wrote: [snip] > > > > > > When the vdso is marked with "sl", mremap() will fail, that's part of > > > the mseal() business logic and belongs in mseal_test. The mseal_test > > > already covers the mseal, and this series doesn't change mseal. > > > > > > As for the "sl", as I responded in the "refactor mseal_test" [1] , it > > > will be part of the verifying step: > > > > > > [1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17mGy-XutSTAwg@xxxxxxxxxxxxxx/ > > > > OK cool thanks. I will look at this when I can, I'm just snowed under > > pre-LSF and have been sick so backlog, backlog as discussed off-list. But > > it's not been forgotten (whiteboard etc. etc.) > > > Ya, no worry about that review, please take time to recover, I will wait. > And appreciate your time and take priority for reviewing this series. Thanks :) [snip] > > > > > > Option two is to create a new path: > > > tools/testing/selftests/sealsysmap. Then, add > > > CONFIG_SEAL_SYSTEM_MAPPING=y to the config file and add a selftest to > > > this path. This seems to be the preferred way by selftest, but we need > > > a new dir for that. > > > > OK I like option 2 let's do this. > > > > But let's call it mseal_system_mappings (yes I"m being nitty again :) I > > really want to try to _explicitly_ say 'mseal' because we have other forms > > of sealing. > > > Sure. Thanks! > > If long path names aren't a problem, I will use mseal_system_mappings, > otherwise mseal_sysmap. I think long form is fine. [snip] > > > > > > In any case, I think the risk is low, and the code changes are quite > > > simple, and fully tested. > > > > Yeah indeed, but I'd really like _something_ if possible. If option 2 is > > relatively quick let's get that sorted out! > > > Great ! I will work on option 2. Perfect cheers! > > Thanks > -Jeff
