Re: [PATCH v2] mm/secretmem: properly account locked pages

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Aug 26, 2026 at 10:39:48AM +0900, Daehyeon Ko wrote:
> Hi Lorenzo,
>
> I tested the exact v2 from this Message-ID on its stated base with an x86_64
> KASAN kernel. The supplied memfd_secret selftest passed 6/6 in three boots,
> and my accounting-boundary suite also passed in three boots. I saw no
> patch-attributable KASAN report, warning, Oops, or panic.
>
> A v1/v2 differential also confirms that v2 fixes the CAP_IPC_LOCK creator
> delegation issue Mike identified:
>
>   v1: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=2
>   v2: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=1
>
> I have one policy question before adding Tested-by. With a one-page soft and
> hard RLIMIT_MEMLOCK, a non-root task whose only effective and permitted
> capability was CAP_IPC_LOCK produced this on v2:
>
>   CAP_ONLY uid=2002 cap_ipc_lock=1 mlock_two_pages=1 faulted_pages=1 raise_hard_rc=-1 raise_hard_errno=1
>
> Thus ordinary mlock() of two pages succeeded, while only one secretmem page
> could be faulted. Raising the hard limit failed with EPERM because that
> requires CAP_SYS_RESOURCE. Is this divergence from ordinary mlock() the
> intended consequence of removing the CAP_IPC_LOCK exemption for secretmem?

I'm not quite sure what you're getting at here, as stated in the patch
CAP_IPC_LOCK does not bypass this limit for secretmem because the scope of
the folios is greater than the process so a process-level capability isn't
suited to bypass it.

Also a typical use case of secretmem is privileged process establishes,
then passes fd to less-privileged user. So it's relatively unique in this
respect and therefore it is not enforced.

The idea is that those with CAP_IPC_LOCK could raise the limits as needed
should they wish to bypass.

>
> I saw the planned selftest split and cleanup in the follow-up discussion. I
> will retest the revised patch before adding Tested-by.

Thanks!

>
> Thanks,
> Daehyeon

--
Cheers, Lorenzo