<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/security/integrity/evm/evm_secfs.c, branch linux-rolling-stable</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-stable'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-10-22T23:24:27Z</updated>
<entry>
<title>ima,evm: move initcalls to the LSM framework</title>
<updated>2025-10-22T23:24:27Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2025-09-02T12:54:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=82fe7932e84f618c6ec217203606f0c27ebef94b'/>
<id>urn:sha1:82fe7932e84f618c6ec217203606f0c27ebef94b</id>
<content type='text'>
This patch converts IMA and EVM to use the LSM frameworks's initcall
mechanism. It moved the integrity_fs_init() call to ima_fs_init() and
evm_init_secfs(), to work around the fact that there is no "integrity" LSM,
and introduced integrity_fs_fini() to remove the integrity directory, if
empty. Both integrity_fs_init() and integrity_fs_fini() support the
scenario of being called by both the IMA and EVM LSMs.

This patch does not touch any of the platform certificate code that
lives under the security/integrity/platform_certs directory as the
IMA/EVM developers would prefer to address that in a future patchset.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
[PM: adjust description as discussed over email]
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
</content>
</entry>
<entry>
<title>evm_secfs: clear securityfs interactions</title>
<updated>2025-06-17T22:10:30Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2024-05-14T05:44:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e25fc5540cdbca3eded4db4bb43709a6ecce3c7d'/>
<id>urn:sha1:e25fc5540cdbca3eded4db4bb43709a6ecce3c7d</id>
<content type='text'>
1) creation never returns NULL; error is reported as ERR_PTR()
2) no need to remove file before removing its parent

Acked-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>fs: port -&gt;setattr() to pass mnt_idmap</title>
<updated>2023-01-19T08:24:02Z</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2023-01-13T11:49:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c1632a0f11209338fc300c66252bcc4686e609e8'/>
<id>urn:sha1:c1632a0f11209338fc300c66252bcc4686e609e8</id>
<content type='text'>
Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner &lt;dchinner@redhat.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner (Microsoft) &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>evm: Don't return an error in evm_write_xattrs() if audit is not enabled</title>
<updated>2021-06-03T14:03:40Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-05-28T07:38:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d721c15fd519c08819fbc6de39b713e2ed1d9894'/>
<id>urn:sha1:d721c15fd519c08819fbc6de39b713e2ed1d9894</id>
<content type='text'>
This patch avoids that evm_write_xattrs() returns an error when audit is
not enabled. The ab variable can be NULL and still be passed to the other
audit_log_() functions, as those functions do not include any instruction.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Verify portable signatures against all protected xattrs</title>
<updated>2021-06-01T19:17:31Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-05-28T07:38:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8c7a703ec9787a1b45b024e9acd253328422dcbd'/>
<id>urn:sha1:8c7a703ec9787a1b45b024e9acd253328422dcbd</id>
<content type='text'>
Currently, the evm_config_default_xattrnames array contains xattr names
only related to LSMs which are enabled in the kernel configuration.
However, EVM portable signatures do not depend on local information and a
vendor might include in the signature calculation xattrs that are not
enabled in the target platform.

Just including all xattrs names in evm_config_default_xattrnames is not a
safe approach, because a target system might have already calculated
signatures or HMACs based only on the enabled xattrs. After applying this
patch, EVM would verify those signatures and HMACs with all xattrs instead.
The non-enabled ones, which could possibly exist, would cause a
verification error.

Thus, this patch adds a new field named enabled to the xattr_list
structure, which is set to true if the LSM associated to a given xattr name
is enabled in the kernel configuration. The non-enabled xattrs are taken
into account only in evm_calc_hmac_or_hash(), if the passed security.evm
type is EVM_XATTR_PORTABLE_DIGSIG.

The new function evm_protected_xattr_if_enabled() has been defined so that
IMA can include all protected xattrs and not only the enabled ones in the
measurement list, if the new template fields xattrnames, xattrlengths or
xattrvalues have been included in the template format.

Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded</title>
<updated>2021-05-21T16:47:08Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-05-14T15:27:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9acc89d31f0c94c8e573ed61f3e4340bbd526d0c'/>
<id>urn:sha1:9acc89d31f0c94c8e573ed61f3e4340bbd526d0c</id>
<content type='text'>
EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to
temporarily disable metadata verification until all xattrs/attrs necessary
to verify an EVM portable signature are copied to the file. This flag is
cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is
calculated on unverified xattrs/attrs.

Currently EVM unnecessarily denies setting this flag if EVM is initialized
with a public key, which is not a concern as it cannot be used to trust
xattrs/attrs updates. This patch removes this limitation.

Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata")
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Cc: stable@vger.kernel.org # 4.16.x
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>evm: fix writing &lt;securityfs&gt;/evm overflow</title>
<updated>2021-05-20T23:48:30Z</updated>
<author>
<name>Mimi Zohar</name>
<email>zohar@linux.ibm.com</email>
</author>
<published>2021-04-26T22:13:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=49219d9b8785ba712575c40e48ce0f7461254626'/>
<id>urn:sha1:49219d9b8785ba712575c40e48ce0f7461254626</id>
<content type='text'>
EVM_SETUP_COMPLETE is defined as 0x80000000, which is larger than INT_MAX.
The "-fno-strict-overflow" compiler option properly prevents signaling
EVM that the EVM policy setup is complete.  Define and read an unsigned
int.

Fixes: f00d79750712 ("EVM: Allow userspace to signal an RSA key has been loaded")
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>fs: make helpers idmap mount aware</title>
<updated>2021-01-24T13:27:20Z</updated>
<author>
<name>Christian Brauner</name>
<email>christian.brauner@ubuntu.com</email>
</author>
<published>2021-01-21T13:19:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=549c7297717c32ee53f156cd949e055e601f67bb'/>
<id>urn:sha1:549c7297717c32ee53f156cd949e055e601f67bb</id>
<content type='text'>
Extend some inode methods with an additional user namespace argument. A
filesystem that is aware of idmapped mounts will receive the user
namespace the mount has been marked with. This can be used for
additional permission checking and also to enable filesystems to
translate between uids and gids if they need to. We have implemented all
relevant helpers in earlier patches.

As requested we simply extend the exisiting inode method instead of
introducing new ones. This is a little more code churn but it's mostly
mechanical and doesnt't leave us with additional inode methods.

Link: https://lore.kernel.org/r/20210121131959.646623-25-christian.brauner@ubuntu.com
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: David Howells &lt;dhowells@redhat.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Christian Brauner &lt;christian.brauner@ubuntu.com&gt;
</content>
</entry>
<entry>
<title>evm: Fix RCU list related warnings</title>
<updated>2020-05-08T01:36:32Z</updated>
<author>
<name>Madhuparna Bhowmik</name>
<email>madhuparnabhowmik10@gmail.com</email>
</author>
<published>2020-04-30T16:02:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=770f60586d2af0590be263f55fd079226313922c'/>
<id>urn:sha1:770f60586d2af0590be263f55fd079226313922c</id>
<content type='text'>
This patch fixes the following warning and few other instances of
traversal of evm_config_xattrnames list:

[   32.848432] =============================
[   32.848707] WARNING: suspicious RCU usage
[   32.848966] 5.7.0-rc1-00006-ga8d5875ce5f0b #1 Not tainted
[   32.849308] -----------------------------
[   32.849567] security/integrity/evm/evm_main.c:231 RCU-list traversed in non-reader section!!

Since entries are only added to the list and never deleted, use
list_for_each_entry_lockless() instead of list_for_each_entry_rcu for
traversing the list.  Also, add a relevant comment in evm_secfs.c to
indicate this fact.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Suggested-by: Paul E. McKenney &lt;paulmck@kernel.org&gt;
Signed-off-by: Madhuparna Bhowmik &lt;madhuparnabhowmik10@gmail.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@kernel.org&gt; (RCU viewpoint)
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>integrity: Remove duplicate pr_fmt definitions</title>
<updated>2020-02-28T19:32:58Z</updated>
<author>
<name>Tushar Sugandhi</name>
<email>tusharsu@linux.microsoft.com</email>
</author>
<published>2020-02-19T00:06:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=555d6d71d57c4a2e4ff750f6a41d2b7d7c861863'/>
<id>urn:sha1:555d6d71d57c4a2e4ff750f6a41d2b7d7c861863</id>
<content type='text'>
The #define for formatting log messages, pr_fmt, is duplicated in the
files under security/integrity.

This change moves the definition to security/integrity/integrity.h and
removes the duplicate definitions in the other files under
security/integrity.

With this change, the messages in the following files will be prefixed
with 'integrity'.

     security/integrity/platform_certs/platform_keyring.c
     security/integrity/platform_certs/load_powerpc.c
     security/integrity/platform_certs/load_uefi.c
     security/integrity/iint.c

     e.g. "integrity: Error adding keys to platform keyring %s\n"

And the messages in the following file will be prefixed with 'ima'.

     security/integrity/ima/ima_mok.c

     e.g. "ima: Allocating IMA blacklist keyring.\n"

For the rest of the files under security/integrity, there will be no
change in the message format.

Suggested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Tushar Sugandhi &lt;tusharsu@linux.microsoft.com&gt;
Reviewed-by: Lakshmi Ramasubramanian &lt;nramas@linux.microsoft.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
</feed>
