lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <68929720cd3b7_184e1f100e4@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 5 Aug 2025 16:43:28 -0700
From: <dan.j.williams@...el.com>
To: Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>, Nikolay Borisov
	<nik.borisov@...e.com>
CC: <linux-security-module@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<paul@...l-moore.com>, <serge@...lyn.com>, <jmorris@...ei.org>,
	<dan.j.williams@...el.com>
Subject: Re: [PATCH v2 0/3] Allow individual features to be locked down

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ