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

[Daehyeon Ko <4ncienth@gmail.com>]

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 saw the planned selftest split and cleanup in the follow-up discussion. I
will retest the revised patch before adding Tested-by.

Thanks,
Daehyeon