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.

Changes since v1:
 * Added Patch 3 to incoroporate Serge's hardening suggestion

Nikolay Borisov (3):
  lockdown: Switch implementation to using bitmap
  lockdown/kunit: Introduce kunit tests
  lockdown: Use snprintf in lockdown_read

 security/lockdown/Kconfig         |  5 +++
 security/lockdown/Makefile        |  1 +
 security/lockdown/lockdown.c      | 36 +++++++++++++++------
 security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
 4 files changed, 86 insertions(+), 10 deletions(-)
 create mode 100644 security/lockdown/lockdown_test.c

--
2.34.1

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 ?

[1]: https://lore.kernel.org/all/CAGXu5j+UWQWDacMvvRCke3xUOb7uTkxn=WaHzG4kJTKWh-6tAA@mail.gmail.com/

Best regards,

Nicolas

---

On Mon, Jul 28, 2025 at 02:15:14PM +0300, Nikolay Borisov wrote:
> 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.
> 
> Changes since v1:
>  * Added Patch 3 to incoroporate Serge's hardening suggestion
> 
> Nikolay Borisov (3):
>   lockdown: Switch implementation to using bitmap
>   lockdown/kunit: Introduce kunit tests
>   lockdown: Use snprintf in lockdown_read
> 
>  security/lockdown/Kconfig         |  5 +++
>  security/lockdown/Makefile        |  1 +
>  security/lockdown/lockdown.c      | 36 +++++++++++++++------
>  security/lockdown/lockdown_test.c | 54 +++++++++++++++++++++++++++++++
>  4 files changed, 86 insertions(+), 10 deletions(-)
>  create mode 100644 security/lockdown/lockdown_test.c
> 
> --
> 2.34.1
>

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 ?

Nikolay already shared some of this but the succinct answer is that COCO
breaks the fundamental expectations of /dev/mem that the only
requirement to map memory is to install a page table entry for it.

For COCO an additional step is needed to decide if the memory is private
to the COCO guest VM (cVM) or shared with the host VMM. If it is private
it additionally must be "accepted" by the cVM before it can be mapped.

/dev/mem allows uncoordinated mapping attempts and at present causes
memory protection violations because the /dev/mem backend attetmps to
map it as shared, but another part of the kernel expects it is only
mapped as cVM-private.

The attempt to communicate the mapping type, control for the acceptance
status resulted in a pile of hacks, or even just add another
COCO-specific check near the existing
"security_locked_down(LOCKDOWN_DEV_MEM)" check were met with "please
just use LOCKDOWN_DEV_MEM" directly and be done.

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.


[0] 
https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/

[1] 
https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/

<snip>

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.

> 
> 
> [0]
> https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/
> 
> [1]
> https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/
> 
> <snip>

On 8/5/25 09:57, 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.
> 

Well the use case that my change allows  (barring the original issue) is 
say if someone wants LOCKDOWN_INTEGRITY_MAX + 1 or 2 things from the 
CONFIDENTIALY_MAX level.

>>
>>
>> [0]
>> https://lore.kernel.org/all/67f69600ed221_71fe2946f@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> [1]
>> https://lore.kernel.org/all/68226ad551afd_29032945b@dwillia2-xfh.jf.intel.com.notmuch/
>>
>> <snip>

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

Hi Nikolay,

After discussing with Xiu, we have decided not to accept this patchset.

The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
having a more granular way to activate Lockdown will break it. Primarily
because most lockdown-reasons can be bypassed if used independently.

Even if the goal of Lockdown were to be redefined, we would need to ensure the
security interdependence between different lockdown-reasons. This is highly
tied to where people calls the `security_locked_down` hook and thus is out of
our maintenance scope.

Having coarse-grained lockdown reasons and integrity/confidentiality levels
allows us to ensure that all of the reasons are correctly locked down.

Best regards,

Nicolas

On 8/14/25 11:59, Nicolas Bouchinet wrote:
> Hi Nikolay,
> 
> After discussing with Xiu, we have decided not to accept this patchset.
> 
> The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
> having a more granular way to activate Lockdown will break it. Primarily
> because most lockdown-reasons can be bypassed if used independently.
> 
> Even if the goal of Lockdown were to be redefined, we would need to ensure the
> security interdependence between different lockdown-reasons. This is highly
> tied to where people calls the `security_locked_down` hook and thus is out of
> our maintenance scope.
> 
> Having coarse-grained lockdown reasons and integrity/confidentiality levels
> allows us to ensure that all of the reasons are correctly locked down.
> 
> Best regards,
> 
> Nicolas

Thanks for the feedback, to try and not have all this code go to waste, 
what about consdering patch 2 - kunits tests. Apart from 
lockdown_test_individual_level() the other tests are applicable to the 
existing lockdown implementation and can aid in future developments?

On Thu, Aug 14, 2025 at 01:02:36PM +0300, Nikolay Borisov wrote:
> 
> 
> On 8/14/25 11:59, Nicolas Bouchinet wrote:
> > Hi Nikolay,
> > 
> > After discussing with Xiu, we have decided not to accept this patchset.
> > 
> > The goal of Lockdown being to draw a clear line between ring-0 and uid-0,
> > having a more granular way to activate Lockdown will break it. Primarily
> > because most lockdown-reasons can be bypassed if used independently.
> > 
> > Even if the goal of Lockdown were to be redefined, we would need to ensure the
> > security interdependence between different lockdown-reasons. This is highly
> > tied to where people calls the `security_locked_down` hook and thus is out of
> > our maintenance scope.
> > 
> > Having coarse-grained lockdown reasons and integrity/confidentiality levels
> > allows us to ensure that all of the reasons are correctly locked down.
> > 
> > Best regards,
> > 
> > Nicolas
> 
> Thanks for the feedback, to try and not have all this code go to waste, what
> about consdering patch 2 - kunits tests. Apart from
> lockdown_test_individual_level() the other tests are applicable to the
> existing lockdown implementation and can aid in future developments?
> 

Yes of course, thanks a lot for those tests. Can you adapt them and send
them separately for review ?

i.e, the `lockdown_test_no_downgrade` should check for -EPERM.

FYI, I have a three week holiday starting today. I'll return on
Septembre the 8th. I let Xiu review those patches until then.