<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/security/integrity/ima/ima_fs.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>ima_fs: get rid of lookup-by-dentry stuff</title>
<updated>2025-06-17T22:10:14Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2025-03-10T16:30:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d15ffbbf4d32a9007c4a339a9fecac90ce30432a'/>
<id>urn:sha1:d15ffbbf4d32a9007c4a339a9fecac90ce30432a</id>
<content type='text'>
lookup_template_data_hash_algo() machinery is used to locate the
matching ima_algo_array[] element at read time; securityfs
allows to stash that into inode-&gt;i_private at object creation
time, so there's no need to bother

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>ima_fs: don't bother with removal of files in directory we'll be removing</title>
<updated>2025-06-17T22:09:52Z</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2024-05-14T05:41:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=22260a99d791163f7697a240dfc48e4e5a91ecfe'/>
<id>urn:sha1:22260a99d791163f7697a240dfc48e4e5a91ecfe</id>
<content type='text'>
removal of parent takes all children out

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>ima: fix wrong zero-assignment during securityfs dentry remove</title>
<updated>2024-06-03T20:37:22Z</updated>
<author>
<name>Enrico Bravi</name>
<email>enrico.bravi@polito.it</email>
</author>
<published>2024-05-29T18:14:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fbf06cee60876d50f259d0689e3c03940750f0d4'/>
<id>urn:sha1:fbf06cee60876d50f259d0689e3c03940750f0d4</id>
<content type='text'>
In case of error during ima_fs_init() all the dentry already created
are removed. {ascii, binary}_securityfs_measurement_lists are freed
calling for each array the remove_securityfs_measurement_lists(). This
function, at the end, assigns to zero the securityfs_measurement_list_count.
This causes during the second call of remove_securityfs_measurement_lists()
to leave the dentry of the array pending, not removing them correctly,
because the securityfs_measurement_list_count is already zero.

Move the securityfs_measurement_list_count = 0 after the two
remove_securityfs_measurement_lists() calls to correctly remove all the
dentry already allocated.

Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Enrico Bravi &lt;enrico.bravi@polito.it&gt;
Reviewed-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: add crypto agility support for template-hash algorithm</title>
<updated>2024-04-12T13:59:04Z</updated>
<author>
<name>Enrico Bravi</name>
<email>enrico.bravi@polito.it</email>
</author>
<published>2024-04-12T09:09:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9fa8e76250082a45d0d3dad525419ab98bd01658'/>
<id>urn:sha1:9fa8e76250082a45d0d3dad525419ab98bd01658</id>
<content type='text'>
The template hash showed by the ascii_runtime_measurements and
binary_runtime_measurements is the one calculated using sha1 and there is
no possibility to change this value, despite the fact that the template
hash is calculated using the hash algorithms corresponding to all the PCR
banks configured in the TPM.

Add the support to retrieve the ima log with the template data hash
calculated with a specific hash algorithm.
Add a new file in the securityfs ima directory for each hash algo
configured in a PCR bank of the TPM. Each new file has the name with
the following structure:

        {binary, ascii}_runtime_measurements_&lt;hash_algo_name&gt;

Legacy files are kept, to avoid breaking existing applications, but as
symbolic links which point to {binary, ascii}_runtime_measurements_sha1
files. These two files are created even if a TPM chip is not detected or
the sha1 bank is not configured in the TPM.

As example, in the case a TPM chip is present and sha256 is the only
configured PCR bank, the listing of the securityfs ima directory is the
following:

lr--r--r-- [...] ascii_runtime_measurements -&gt; ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha256
lr--r--r-- [...] binary_runtime_measurements -&gt; binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha256
--w------- [...] policy
-r--r----- [...] runtime_measurements_count
-r--r----- [...] violations

Signed-off-by: Enrico Bravi &lt;enrico.bravi@polito.it&gt;
Signed-off-by: Silvia Sisinni &lt;silvia.sisinni@polito.it&gt;
Reviewed-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Return error code obtained from securityfs functions</title>
<updated>2022-02-15T16:17:01Z</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-02-01T20:37:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e4e071baea41e43aebd7f17ed1ffceeca6aa9868'/>
<id>urn:sha1:e4e071baea41e43aebd7f17ed1ffceeca6aa9868</id>
<content type='text'>
If an error occurs when creating a securityfs file, return the exact
error code to the caller.

Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Remove ima_policy file before directory</title>
<updated>2022-02-02T16:59:09Z</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-01-25T22:46:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f7333b9572d0559e00352a926c92f29f061b4569'/>
<id>urn:sha1:f7333b9572d0559e00352a926c92f29f061b4569</id>
<content type='text'>
The removal of ima_dir currently fails since ima_policy still exists, so
remove the ima_policy file before removing the directory.

Fixes: 4af4662fa4a9 ("integrity: IMA policy")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima/evm: Fix type mismatch</title>
<updated>2021-06-08T20:29:10Z</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-06-08T12:31:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6b26285f44c9306747c609cb304f787f1933594c'/>
<id>urn:sha1:6b26285f44c9306747c609cb304f787f1933594c</id>
<content type='text'>
The endianness of a variable written to the measurement list cannot be
determined at compile time, as it depends on the value of the
ima_canonical_fmt global variable (set through a kernel option with the
same name if the machine is big endian).

If ima_canonical_fmt is false, the endianness of a variable is the same as
the machine; if ima_canonical_fmt is true, the endianness is little endian.
The warning arises due to this type of instruction:

var = cpu_to_leXX(var)

which tries to assign a value in little endian to a variable with native
endianness (little or big endian).

Given that the variables set with this instruction are not used in any
operation but just written to a buffer, it is safe to force the type of the
value being set to be the same of the type of the variable with:

var = (__force &lt;var type&gt;)cpu_to_leXX(var)

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
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>fs/kernel_file_read: Add "offset" arg for partial reads</title>
<updated>2020-10-05T11:37:04Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-10-02T17:38:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0fa8e084648779eeb8929ae004301b3acf3bad84'/>
<id>urn:sha1:0fa8e084648779eeb8929ae004301b3acf3bad84</id>
<content type='text'>
To perform partial reads, callers of kernel_read_file*() must have a
non-NULL file_size argument and a preallocated buffer. The new "offset"
argument can then be used to seek to specific locations in the file to
fill the buffer to, at most, "buf_size" per call.

Where possible, the LSM hooks can report whether a full file has been
read or not so that the contents can be reasoned about.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lore.kernel.org/r/20201002173828.2099543-14-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fs/kernel_read_file: Add file_size output argument</title>
<updated>2020-10-05T11:37:03Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-10-02T17:38:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=885352881f11f1f3113d8eb877786bcb6d720544'/>
<id>urn:sha1:885352881f11f1f3113d8eb877786bcb6d720544</id>
<content type='text'>
In preparation for adding partial read support, add an optional output
argument to kernel_read_file*() that reports the file size so callers
can reason more easily about their reading progress.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Reviewed-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Reviewed-by: James Morris &lt;jamorris@linux.microsoft.com&gt;
Acked-by: Scott Branden &lt;scott.branden@broadcom.com&gt;
Link: https://lore.kernel.org/r/20201002173828.2099543-8-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
