Dan Williams wrote:

Paul Moore wrote:

quoted

On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov [off-list ref] wrote:

quoted

This simple change allows usecases where someone might want to  lock only specific
feature at a finer granularity than integrity/confidentiality levels allows.
The first likely user of this is the CoCo subsystem where certain features will be
disabled.

Nikolay Borisov (2):
  lockdown: Switch implementation to using bitmap
  lockdown/kunit: Introduce kunit tests

Hi Nikolay,

Thanks for the patches!  With the merge window opening in a few days,
it is too late to consider this for the upcoming merge window so
realistically this patchset is two weeks out and I'm hopeful we'll
have a dedicated Lockdown maintainer by then so I'm going to defer the
ultimate decision on acceptance to them.

The patches in this thread proposed to selectively disable /dev/mem
independent of all the other lockdown mitigations. That goal can be
achieved with more precision with this proposed patch:

http://lore.kernel.org/67f5b75c37143_71fe2949b@dwillia2-xfh.jf.intel.com.notmuch (local)

Just wanted to circle back here and repair the damage I caused to the
momentum of this "lockdown feature bitmap" proposal. It turns out that
devmem maintainers are not looking to add yet more arch-specific hacks
[1].

    "Restricting /dev/mem further is a good idea, but it would be nice
     if that could be done without adding yet another special case."

security_locked_down() is already plumbed into all the places that
confidential VMs may need to manage userspace access to confidential /
private memory.

I considered registering a new "coco-LSM" to hook
security_locked_down(), but that immediately raises the next question of
how does userspace discover what is currently locked_down. So just teach
the native lockdown LSM how to be more fine-grained rather than
complicate the situation with a new LSM.

[1]: http://lore.kernel.org/0bdb1876-0cb3-4632-910b-2dc191902e3e@app.fastmail.com (local)