security/lockdown/Kconfig | 5 +++ security/lockdown/Makefile | 1 + security/lockdown/lockdown.c | 24 +++++++++----- security/lockdown/lockdown_test.c | 55 +++++++++++++++++++++++++++++++ 4 files changed, 77 insertions(+), 8 deletions(-) create mode 100644 security/lockdown/lockdown_test.c
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 security/lockdown/Kconfig | 5 +++ security/lockdown/Makefile | 1 + security/lockdown/lockdown.c | 24 +++++++++----- security/lockdown/lockdown_test.c | 55 +++++++++++++++++++++++++++++++ 4 files changed, 77 insertions(+), 8 deletions(-) create mode 100644 security/lockdown/lockdown_test.c -- 2.43.0
On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. > > 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. -- paul-moore.com
On Fri, Mar 21, 2025 at 5:13 PM Paul Moore <paul@paul-moore.com> wrote: > On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. > > > > 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. FYI, I expect we'll see something on the mailing list related to this soon. -- paul-moore.com
Paul Moore wrote: > On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. > > > > 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
Dan Williams wrote:
> Paul Moore wrote:
> > On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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.
> > >
> > > 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
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
On Mon, May 12, 2025 at 5:41 PM Dan Williams <dan.j.williams@intel.com> wrote: > Dan Williams wrote: > > Paul Moore wrote: > > > On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. > > > > > > > > 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 > > 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. Historically Linus has bristled at LSMs with alternative security_locked_down() implementations/security-models, therefore I'd probably give a nod to refining the existing Lockdown approach over a new LSM. Related update, there are new Lockdown maintainers coming, there is just an issue of sorting out some email addresses first. Hopefully we'll see something on-list soon. -- paul-moore.com
On 5/13/25 01:01, Paul Moore wrote: > On Mon, May 12, 2025 at 5:41 PM Dan Williams <dan.j.williams@intel.com> wrote: >> Dan Williams wrote: >>> Paul Moore wrote: >>>> On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. >>>>> >>>>> 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 >> >> 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. > > Historically Linus has bristled at LSMs with alternative > security_locked_down() implementations/security-models, therefore I'd > probably give a nod to refining the existing Lockdown approach over a > new LSM. > > Related update, there are new Lockdown maintainers coming, there is > just an issue of sorting out some email addresses first. Hopefully > we'll see something on-list soon. > So I guess the most sensible way forward will be to resend these 2 patches after the new maintainer has been officially announced?
On Tue, May 13, 2025 at 7:10 AM Nikolay Borisov <nik.borisov@suse.com> wrote: > On 5/13/25 01:01, Paul Moore wrote: > > On Mon, May 12, 2025 at 5:41 PM Dan Williams <dan.j.williams@intel.com> wrote: > >> Dan Williams wrote: > >>> Paul Moore wrote: > >>>> On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. > >>>>> > >>>>> 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 > >> > >> 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. > > > > Historically Linus has bristled at LSMs with alternative > > security_locked_down() implementations/security-models, therefore I'd > > probably give a nod to refining the existing Lockdown approach over a > > new LSM. > > > > Related update, there are new Lockdown maintainers coming, there is > > just an issue of sorting out some email addresses first. Hopefully > > we'll see something on-list soon. > > So I guess the most sensible way forward will be to resend these 2 > patches after the new maintainer has been officially announced? Possibly, or at least bump the thread to get it some fresh attention. -- paul-moore.com
On 9.04.25 г. 18:45 ч., Dan Williams wrote: > Paul Moore wrote: >> On Fri, Mar 21, 2025 at 6:24 AM Nikolay Borisov <nik.borisov@suse.com> 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. >>> >>> 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 True, however I think increasing the granularity of the lockdown subsystem merits its own discussion, notwithstanding COCO use case.
© 2016 - 2025 Red Hat, Inc.