Re: [PATCH v2 0/3] Allow individual features to be locked down

[<dan.j.williams@intel.com>]

xiujianfeng wrote:
> 
> 
> On 2025/7/29 20:25, Nikolay Borisov wrote:
> > 
> > 
> > On 29.07.25 г. 15:16 ч., Nicolas Bouchinet wrote:
> >> Hi Nikolay,
> >>
> >> Thanks for you patch.
> >>
> >> Quoting Kees [1], Lockdown is "about creating a bright line between
> >> uid-0 and ring-0".
> >>
> >> Having a bitmap enabled Lockdown would mean that Lockdown reasons could
> >> be activated independently. I fear this would lead to a false sense of
> >> security, locking one reason alone often permits Lockdown restrictions
> >> bypass. i.e enforcing kernel module signature verification but not
> >> blocking accesses to `/dev/{k,}mem` or authorizing gkdb which can be
> >> used to disable the module signature enforcement.
> >>
> >> If one wants to restrict accesses to `/dev/mem`,
> >> `security_locked_down(LOCKDOWN_DEV_MEM)` should be sufficient.
> >>
> >> My understanding of your problem is that this locks too much for your
> >> usecase and you want to restrict reasons of Lockdown independently in
> >> case it has not been enabled in "integrity" mode by default ?
> >>
> >> Can you elaborate more on the usecases for COCO ?
> > 
> > Initially this patchset was supposed to allow us selectively disable
> > /dev/iomem access in a CoCo context [0]. As evident from Dan's initial
> > response that point pretty much became moot as the issue was fixed in a
> > different way. However, later [1] he came back and said that actually
> > this patch could be useful in a similar context. So This v2 is
> > essentially following up on that.
> 
> Hi Nikolay,
> 
> I share a similar view with Nicolas, namely that using a bitmap
> implementation would compromise the goal of Lockdown.
> 
> After reading the threads below, I understand you aim is to block user
> access to /dev/mem, but without having Lockdown integrity mode enabled
> to block other reasons, right? How about using BPF LSM? It seems it
> could address your requirements.

BPF LSM does not seem suitable for the main concern which is that arch
code needs hard guarantess that certain code paths are disabled. For
Confidential Computing it needs to know that userspace access of
/dev/mem is always disabled.

This is a functional concern, not a security concern. Both Arnd [1] and
Greg [2] lamented needing new hacks to achieve the same outcome as just
reusing the existing security_locked_down() checks. The
SECURITY_LOCKDOWN_LSM already has /sys/kernel/security/lockdown ABI for
communicating built-in and now kernel-internal sources of locked
functionality.

[1]: http://lore.kernel.org/0bdb1876-0cb3-4632-910b-2dc191902e3e@app.fastmail.com
[2]: http://lore.kernel.org/2025043025-cathouse-headlamp-7bde@gregkh