> From: Roberto Sassu > Sent: Tuesday, September 14, 2021 6:34 PM > Status > ====== > > This version of the patch set implements the suggestions received for > version 2. Apart from one patch added for the IMA API and few fixes, there > are no substantial changes. It has been tested on: x86_64, UML (x86_64), > s390x (big endian). Hi everyone I didn't receive comments on this version. I believe it is ready to be accepted, as I addressed the comments for the previous versions and the tests I wrote are sufficiently complete to find possible problems. Is there anything I could do to increase the chances of acceptance? Would moving DIGLIM to security/ instead of security/integrity/ make it more suitable for inclusion? Thanks Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > The long term goal is to boot a system with appraisal enabled and with > DIGLIM as repository for reference values, taken from the RPM database. > > Changes required: > - new execution policies in IMA > (https://lore.kernel.org/linux-integrity/20210409114313.4073-1- > roberto.sassu@xxxxxxxxxx/) > - support for the euid policy keyword for critical data > (https://lore.kernel.org/linux-integrity/20210705115650.3373599-1- > roberto.sassu@xxxxxxxxxx/) > - basic DIGLIM > (this patch set) > - additional DIGLIM features (loader, LSM, user space utilities) > - support for DIGLIM in IMA > - support for PGP keys and signatures > (from David Howells) > - support for PGP appended signatures in IMA > > > Introduction > ============ > > Digest Lists Integrity Module (DIGLIM) is a component of the integrity > subsystem in the kernel, primarily aiming to aid Integrity Measurement > Architecture (IMA) in the process of checking the integrity of file > content and metadata. It accomplishes this task by storing reference > values coming from software vendors and by reporting whether or not the > digest of file content or metadata calculated by IMA (or EVM) is found > among those values. In this way, IMA can decide, depending on the result > of a query, if a measurement should be taken or access to the file > should be granted. The Security Assumptions section explains more in > detail why this component has been placed in the kernel. > > The main benefits of using IMA in conjunction with DIGLIM are the > ability to implement advanced remote attestation schemes based on the > usage of a TPM key for establishing a TLS secure channel[1][2], and to > reduce the burden on Linux distribution vendors to extend secure boot at > OS level to applications. > > DIGLIM does not have the complexity of feature-rich databases. In fact, > its main functionality comes from the hash table primitives already in > the kernel. It does not have an ad-hoc storage module, it just indexes > data in a fixed format (digest lists, a set of concatenated digests > preceded by a header), copied to kernel memory as they are. Lastly, it > does not support database-oriented languages such as SQL, but only > accepts a digest and its algorithm as a query. > > The only digest list format supported by DIGLIM is called compact. > However, Linux distribution vendors don't have to generate new digest > lists in this format for the packages they release, as already available > information, such as RPM headers and DEB package metadata, can be used > as a source for reference values (they include file digests), with a > user space parser taking care of the conversion to the compact format. > > Although one might perceive that storing file or metadata digests for a > Linux distribution would significantly increase the memory usage, this > does not seem to be the case. As an anticipation of the evaluation done > in the Preliminary Performance Evaluation section, protecting binaries > and shared libraries of a minimal Fedora 33 installation requires 208K > of memory for the digest lists plus 556K for indexing. > > In exchange for a slightly increased memory usage, DIGLIM improves the > performance of the integrity subsystem. In the considered scenario, IMA > measurement and appraisal of 5896 files with digest lists requires > respectively less than one quarter and less than half the time, compared > to the current solution. > > DIGLIM also keeps track of whether digest lists have been processed in > some way (e.g. measured or appraised by IMA). This is important for > example for remote attestation, so that remote verifiers understand what > has been uploaded to the kernel. > > Operations in DIGLIM are atomic: if an error occurs during the addition > of a digest list, DIGLIM rolls back the entire insert operation; > deletions instead always succeed. This capability has been tested with > an ad-hoc fault injection mechanism capable of simulating failures > during the operations. > > Finally, DIGLIM exposes to user space, through securityfs, the digest > lists currently loaded, the number of digests added, a query interface > and an interface to set digest list labels. > > > Binary Integrity > > Integrity is a fundamental security property in information systems. > Integrity could be described as the condition in which a generic > component is just after it has been released by the entity that created > it. > > One way to check whether a component is in this condition (called binary > integrity) is to calculate its digest and to compare it with a reference > value (i.e. the digest calculated in controlled conditions, when the > component is released). > > IMA, a software part of the integrity subsystem, can perform such > evaluation and execute different actions: > > - store the digest in an integrity-protected measurement list, so that > it can be sent to a remote verifier for analysis; > - compare the calculated digest with a reference value (usually > protected with a signature) and deny operations if the file is found > corrupted; > - store the digest in the system log. > > > Benefits > > DIGLIM further enhances the capabilities offered by IMA-based solutions > and, at the same time, makes them more practical to adopt by reusing > existing sources as reference values for integrity decisions. > > Possible sources for digest lists are: > > - RPM headers; > - Debian repository metadata. > > Benefits for IMA Measurement > > One of the issues that arises when files are measured by the OS is that, > due to parallel execution, the order in which file accesses happen > cannot be predicted. Since the TPM Platform Configuration Register (PCR) > extend operation, executed after each file measurement, > cryptographically binds the current measurement to the previous ones, > the PCR value at the end of a workload cannot be predicted too. > > Thus, even if the usage of a TPM key, bound to a PCR value, should be > allowed when only good files were accessed, the TPM could unexpectedly > deny an operation on that key if files accesses did not happen as stated > by the key policy (which allows only one of the possible sequences). > > DIGLIM solves this issue by making the PCR value stable over the time > and not dependent on file accesses. The following figure depicts the > current and the new approaches: > > IMA measurement list (current) > > entry# 1st boot 2nd boot 3rd boot > +----+---------------+ +----+---------------+ +----+---------------+ > 1: | 10 | file1 measur. | | 10 | file3 measur. | | 10 | file2 measur. | > +----+---------------+ +----+---------------+ +----+---------------+ > 2: | 10 | file2 measur. | | 10 | file2 measur. | | 10 | file3 measur. | > +----+---------------+ +----+---------------+ +----+---------------+ > 3: | 10 | file3 measur. | | 10 | file1 measur. | | 10 | file4 measur. | > +----+---------------+ +----+---------------+ +----+---------------+ > > PCR: Extend != Extend != Extend > file1, file2, file3 file3, file2, file1 file2, file3, file4 > > > PCR Extend definition: > > PCR(new value) = Hash(Hash(meas. entry), PCR(previous value)) > > A new entry in the measurement list is created by IMA for each file > access. Assuming that file1, file2 and file3 are files provided by the > software vendor, file4 is an unknown file, the first two PCR values > above represent a good system state, the third a bad system state. The > PCR values are the result of the PCR extend operation performed for each > measurement entry with the digest of the measurement entry as an input. > > IMA measurement list (with DIGLIM) > > dlist > +--------------+ > | header | > +--------------+ > | file1 digest | > | file2 digest | > | file3 digest | > +--------------+ > > dlist is a digest list containing the digest of file1, file2 and file3. > In the intended scenario, it is generated by a software vendor at the > end of the building process, and retrieved by the administrator of the > system where the digest list is loaded. > > entry# 1st boot 2nd boot 3rd boot > +----+---------------+ +----+---------------+ +----+---------------+ > 0: | 11 | dlist measur. | | 11 | dlist measur. | | 11 | dlist measur. | > +----+---------------+ +----+---------------+ +----+---------------+ > 1: < file1 measur. skip > < file3 measur. skip > < file2 measur. skip > > > 2: < file2 measur. skip > < file2 measur. skip > < file3 measur. skip > > +----+---------------+ > 3: < file3 measur. skip > < file1 measur. skip > | 11 | file4 measur. | > +----+---------------+ > > PCR: Extend = Extend != Extend > dlist dlist dlist, file4 > > The first entry in the measurement list contains the digest of the > digest list uploaded to the kernel at kernel initialization time. > > When a file is accessed, IMA queries DIGLIM with the calculated file > digest and, if it is found, IMA skips the measurement. > > Thus, the only information sent to remote verifiers are: the list of > files that could possibly be accessed (from the digest list), but not if > they were accessed and when; the measurement of unknown files. > > Despite providing less information, this solution has the advantage that > the good system state (i.e. when only file1, file2 and file3 are > accessed) now can be represented with a deterministic PCR value (the PCR > is extended only with the measurement of the digest list). Also, the bad > system state can still be distinguished from the good state (the PCR is > extended also with the measurement of file4). > > If a TPM key is bound to the good PCR value, the TPM would allow the key > to be used if file1, file2 or file3 are accessed, regardless of the > sequence in which they are accessed (the PCR value does not change), and > would revoke the permission when the unknown file4 is accessed (the PCR > value changes). If a system is able to establish a TLS connection with a > peer, this implicitly means that the system was in a good state (i.e. > file4 was not accessed, otherwise the TPM would have denied the usage of > the TPM key due to the key policy). > > Benefits for IMA Appraisal > > Extending secure boot to applications means being able to verify the > provenance of files accessed. IMA does it by verifying file signatures > with a key that it trusts, which requires Linux distribution vendors to > additionally include in the package header a signature for each file > that must be verified (there is the dedicated RPMTAG_FILESIGNATURES > section in the RPM header). > > The proposed approach would be instead to verify data provenance from > already available metadata (file digests) in existing packages. IMA > would verify the signature of package metadata and search file digests > extracted from package metadata and added to the hash table in the > kernel. > > For RPMs, file digests can be found in the RPMTAG_FILEDIGESTS section of > RPMTAG_IMMUTABLE, whose signature is in RPMTAG_RSAHEADER. For DEBs, > file > digests (unsafe to use due to a weak digest algorithm) can be found in > the md5sum file, which can be indirectly verified from Release.gpg. > > The following figure highlights the differences between the current and > the proposed approach. > > IMA appraisal (current solution, with file signatures): > > appraise > +-----------+ > V | > +-------------------------+-----+ +-------+-----+ | > | RPM header | | ima rpm | file1 | sig | | > | ... | | plugin +-------+-----+ +-----+ > | file1 sig [to be added] | sig |--------> ... | IMA | > | ... | | +-------+-----+ +-----+ > | fileN sig [to be added] | | | fileN | sig | > +-------------------------+-----+ +-------+-----+ > > In this case, file signatures must be added to the RPM header, so that > the ima rpm plugin can extract them together with the file content. The > RPM header signature is not used. > > IMA appraisal (with DIGLIM): > > kernel hash table > with RPM header content > +---+ +--------------+ > | |--->| file1 digest | > +---+ +--------------+ > ... > +---+ appraise (file1) > | | <--------------+ > +----------------+-----+ +---+ | > | RPM header | | ^ | > | ... | | digest_list | | > | file1 digest | sig | rpm plugin | +-------+ +-----+ > | ... | |-------------+--->| file1 | | IMA | > | fileN digest | | +-------+ +-----+ > +----------------+-----+ | > ^ | > +------------------------------------+ > appraise (RPM header) > > In this case, the RPM header is used as it is, and its signature is used > for IMA appraisal. Then, the digest_list rpm plugin executes the user > space parser to parse the RPM header and add the extracted digests to an > hash table in the kernel. IMA appraisal of the files in the RPM package > consists in searching their digest in the hash table. > > Other than reusing available information as digest list, another > advantage is the lower computational overhead compared to the solution > with file signatures (only one signature verification for many files and > digest lookup, instead of per file signature verification, see > Preliminary Performance Evaluation for more details). > > > Lifecycle > > The lifecycle of DIGLIM is represented in the following figure: > > Vendor premises (release process with modifications): > > +------------+ +-----------------------+ +------------------------+ > | 1. build a | | 2. generate and sign | | 3. publish the package | > | package |-->| a digest list from |-->| and digest list in | > | | | packaged files | | a repository | > +------------+ +-----------------------+ +------------------------+ > | > | > User premises: | > V > +---------------------+ +------------------------+ +-----------------+ > | 6. use digest lists | | 5. download the digest | | 4. download and | > | for measurement |<--| list and upload to |<--| install the | > | and/or appraisal | | the kernel | | package | > +---------------------+ +------------------------+ +-----------------+ > > The figure above represents all the steps when a digest list is > generated separately. However, as mentioned in Benefits, in most cases > existing packages can be already used as a source for digest lists, > limiting the effort for software vendors. > > If, for example, RPMs are used as a source for digest lists, the figure > above becomes: > > Vendor premises (release process without modifications): > > +------------+ +------------------------+ > | 1. build a | | 2. publish the package | > | package |-->| in a repository |---------------------+ > | | | | | > +------------+ +------------------------+ | > | > | > User premises: | > V > +---------------------+ +------------------------+ +-----------------+ > | 5. use digest lists | | 4. extract digest list | | 3. download and | > | for measurement |<--| from the package |<--| install the | > | and/or appraisal | | and upload to the | | package | > | | | kernel | | | > +---------------------+ +------------------------+ +-----------------+ > > Step 4 can be performed with the digest_list rpm plugin and the user > space parser, without changes to rpm itself. > > > Security Assumptions > > As mentioned in the Introduction, DIGLIM will be primarily used in > conjunction with IMA to enforce a mandatory policy on all user space > processes, including those owned by root. Even root, in a system with a > locked-down kernel, cannot affect the enforcement of the mandatory > policy or, if changes are permitted, it cannot do so without being > detected. > > Given that the target of the enforcement are user space processes, > DIGLIM cannot be placed in the target, as a Mandatory Access Control > (MAC) design is required to have the components responsible to enforce > the mandatory policy separated from the target. > > While locking-down a system and limiting actions with a mandatory policy > is generally perceived by users as an obstacle, it has noteworthy > benefits for the users themselves. > > First, it would timely block attempts by malicious software to steal or > misuse user assets. Although users could query the package managers to > detect them, detection would happen after the fact, or it wouldn't > happen at all if the malicious software tampered with package managers. > With a mandatory policy enforced by the kernel, users would still be > able to decide which software they want to be executed except that, > unlike package managers, the kernel is not affected by user space > processes or root. > > Second, it might make systems more easily verifiable from outside, due > to the limited actions the system allows. When users connect to a > server, not only they would be able to verify the server identity, which > is already possible with communication protocols like TLS, but also if > the software running on that server can be trusted to handle their > sensitive data. > > > Adoption > > A former version of DIGLIM is used in the following OSes: > > - openEuler 20.09 > https://github.com/openeuler-mirror/kernel/tree/openEuler-20.09 > - openEuler 21.03 > https://github.com/openeuler-mirror/kernel/tree/openEuler-21.03 > > Originally, DIGLIM was part of IMA (known as IMA Digest Lists). In this > version, it has been redesigned as a standalone module with an API that > makes its functionality accessible by IMA and, eventually, other > subsystems. > > > User Space Support > > Digest lists can be generated and managed with digest-list-tools: > > https://github.com/openeuler-mirror/digest-list-tools > > It includes two main applications: > > - gen_digest_lists: generates digest lists from files in the > filesystem or from the RPM database (more digest list sources can be > supported); > - manage_digest_lists: converts and uploads digest lists to the > kernel. > > Integration with rpm is done with the digest_list plugin: > > https://gitee.com/src-openeuler/rpm/blob/master/Add-digest-list-plugin.patch > > This plugin writes the RPM header and its signature to a file, so that > the file is ready to be appraised by IMA, and calls the user space > parser to convert and upload the digest list to the kernel. > > > Simple Usage Example (Tested with Fedora 33) > > 1. Digest list generation (RPM headers and their signature are copied > to the specified directory): > > # mkdir /etc/digest_lists > # gen_digest_lists -t file -f rpm+db -d /etc/digest_lists -o add > > 2. Digest list upload with the user space parser: > > # manage_digest_lists -p add-digest -d /etc/digest_lists > > 3. First digest list query: > > # echo sha256-$(sha256sum /bin/cat) > > /sys/kernel/security/integrity/diglim/digest_query > # cat /sys/kernel/security/integrity/diglim/digest_query > sha256-[...]-0-file_list-rpm-coreutils-8.32-18.fc33.x86_64 (actions: 0): > version: 1, algo: sha256, type: 2, modifiers: 1, count: 106, datalen: 3392 > > 4. Second digest list query: > > # echo sha256-$(sha256sum /bin/zip) > > /sys/kernel/security/integrity/diglim/digest_query > # cat /sys/kernel/security/integrity/diglim/digest_query > sha256-[...]-0-file_list-rpm-zip-3.0-27.fc33.x86_64 (actions: 0): version: 1, > algo: sha256, type: 2, modifiers: 1, count: 4, datalen: 128 > > > Preliminary Performance Evaluation > > This section provides an initial estimation of the overhead introduced > by DIGLIM. The estimation has been performed on a Fedora 33 virtual > machine with 1447 packages installed. The virtual machine has 16 vCPU > (host CPU: AMD Ryzen Threadripper PRO 3955WX 16-Cores) and 2G of RAM > (host memory: 64G). The virtual machine also has a vTPM with libtpms and > swtpm as backend. > > After writing the RPM headers to files, the size of the directory > containing them is 36M. > > After converting the RPM headers to the compact digest list, the size of > the data being uploaded to the kernel is 3.6M. > > The time to load the entire RPM database is 0.628s. > > After loading the digest lists to the kernel, the slab usage due to > indexing is (obtained with slab_nomerge in the kernel command line): > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 118144 118144 100% 0,03K 923 128 3692K > digest_list_item_ref_cache > 102400 102400 100% 0,03K 800 128 3200K digest_item_cache > 2646 2646 100% 0,09K 63 42 252K digest_list_item_cache > > The stats, obtained from the digests_count interface, introduced later, > are: > > Parser digests: 0 > File digests: 99100 > Metadata digests: 0 > Digest list digests: 1423 > > On this installation, this would be the worst case in which all files > are measured and/or appraised, which is currently not recommended > without enforcing an integrity policy protecting mutable files. Infoflow > LSM is a component to accomplish this task: > > https://patchwork.kernel.org/project/linux- > integrity/cover/20190818235745.1417-1-roberto.sassu@xxxxxxxxxx/ > > The first manageable goal of IMA with DIGLIM is to use an execution > policy, with measurement and/or appraisal of files executed or mapped in > memory as executable (in addition to kernel modules and firmware). In > this case, the digest list contains the digest only for those files. The > numbers above change as follows. > > After converting the RPM headers to the compact digest list, the size of > the data being uploaded to the kernel is 208K. > > The time to load the digest of binaries and shared libraries is 0.062s. > > After loading the digest lists to the kernel, the slab usage due to > indexing is: > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 7168 7168 100% 0,03K 56 128 224K digest_list_item_ref_cache > 7168 7168 100% 0,03K 56 128 224K digest_item_cache > 1134 1134 100% 0,09K 27 42 108K digest_list_item_cache > > The stats, obtained from the digests_count interface, are: > > Parser digests: 0 > File digests: 5986 > Metadata digests: 0 > Digest list digests: 1104 > > Comparison with IMA > > This section compares the performance between the current solution for > IMA measurement and appraisal, and IMA with DIGLIM. > > Workload A (without DIGLIM): > > 1. cat file[0-5985] > /dev/null > > Workload B (with DIGLIM): > > 1. echo $PWD/0-file_list-compact-file[0-1103] > > <securityfs>/integrity/diglim/digest_list_add > 2. cat file[0-5985] > /dev/null > > Workload A execution time without IMA policy: > > real 0m0,155s > user 0m0,008s > sys 0m0,066s > > Measurement > > IMA policy: > > measure fowner=2000 func=FILE_CHECK mask=MAY_READ use_diglim=allow > pcr=11 ima_template=ima-sig > > use_diglim is a policy keyword not yet supported by IMA. > > Workload A execution time with IMA and 5986 files with signature > measured: > > real 0m8,273s > user 0m0,008s > sys 0m2,537s > > Workload B execution time with IMA, 1104 digest lists with signature > measured and uploaded to the kernel, and 5986 files with signature > accessed but not measured (due to the file digest being found in the > hash table): > > real 0m1,837s > user 0m0,036s > sys 0m0,583s > > Appraisal > > IMA policy: > > appraise fowner=2000 func=FILE_CHECK mask=MAY_READ use_diglim=allow > > use_diglim is a policy keyword not yet supported by IMA. > > Workload A execution time with IMA and 5986 files with file signature > appraised: > > real 0m2,197s > user 0m0,011s > sys 0m2,022s > > Workload B execution time with IMA, 1104 digest lists with signature > appraised and uploaded to the kernel, and with 5986 files with signature > not verified (due to the file digest being found in the hash table): > > real 0m0,982s > user 0m0,020s > sys 0m0,865s > > [1] LSS EU 2019 slides and video > > [2] FutureTPM EU project, final review meeting demo slides and video > > v2: > - fix documentation content and style issues (suggested by Mauro) > - fix basic definitions description and ensure that the _reserved field of > compact list headers is zero (suggested by Greg KH) > - document the static inline functions to access compact list data > (suggested by Mauro) > - rename htable global variable to diglim_htable (suggested by Mauro) > - add IMA API to retrieve integrity information about a file or buffer > - display the digest list in the original format (same endianness as when > it was uploaded) > - support digest lists with appended signature (for IMA appraisal) > - fix bugs in the tests > - allocate the digest list label in digest_list_add() > - rename digest_label interface to digest_list_label > - check input for digest_query and digest_list_label interfaces > - don't remove entries in digest_lists_loaded if the same digest list is > uploaded again to the kernel > - deny write access to the digest lists while IMA actions are retrieved > - add new test digest_list_add_del_test_file_upload_measured_chown > - remove unused COMPACT_KEY type > > v1: > - remove 'ima: Add digest, algo, measured parameters to > ima_measure_critical_data()', replaced by: > https://lore.kernel.org/linux-integrity/20210705090922.3321178-1- > roberto.sassu@xxxxxxxxxx/ > - add 'Lifecycle' subsection to better clarify how digest lists are > generated and used (suggested by Greg KH) > - remove 'Possible Usages' subsection and add 'Benefits for IMA > Measurement' and 'Benefits for IMA Appraisal' subsubsections > - add 'Preliminary Performance Evaluation' subsection > - declare digest_offset and hdr_offset in the digest_list_item_ref > structure as u32 (sufficient for digest lists of 4G) to make room for a > list_head structure (digest_list_item_ref size: 32) > - implement digest list reference management with a linked list instead of > an array > - reorder structure members for better alignment (suggested by Mauro) > - rename digest_lookup() to __digest_lookup() (suggested by Mauro) > - introduce an object cache for each defined structure > - replace atomic_long_t with unsigned long in h_table structure definition > (suggested by Greg KH) > - remove GPL2 license text and file names (suggested by Greg KH) > - ensure that the _reserved field of compact_list_hdr is equal to zero > (suggested by Greg KH) > - dynamically allocate the buffer in digest_lists_show_htable_len() to > avoid frame size warning (reported by kernel test robot, dynamic > allocation suggested by Mauro) > - split documentation in multiple files and reference the source code > (suggested by Mauro) > - use #ifdef in include/linux/diglim.h > - improve generation of event name for IMA measurements > - add new patch to introduce the 'Remote Attestation' section in the > documentation > - fix assignment of actions variable in digest_list_read() and > digest_list_write() > - always release dentry reference when digest_list_get_secfs_files() is > called > - rewrite add/del and query interfaces to take advantage of m->private > - prevent deletion of a digest list only if there are actions done at > addition time that are not currently being performed > - fix doc warnings (replace Returns with Return:) > - perform queries of digest list digests in the existing tests > - add new tests: digest_list_add_del_test_file_upload_measured, > digest_list_check_measurement_list_test_file_upload and > digest_list_check_measurement_list_test_buffer_upload > - don't return a value from digest_del(), digest_list_ref_del, and > digest_list_del() > - improve Makefile for tests > > Roberto Sassu (13): > diglim: Overview > diglim: Basic definitions > diglim: Objects > diglim: Methods > diglim: Parser > diglim: IMA info > diglim: Interfaces - digest_list_add, digest_list_del > diglim: Interfaces - digest_lists_loaded > diglim: Interfaces - digest_list_label > diglim: Interfaces - digest_query > diglim: Interfaces - digests_count > diglim: Remote Attestation > diglim: Tests > > .../security/diglim/architecture.rst | 46 + > .../security/diglim/implementation.rst | 228 +++ > Documentation/security/diglim/index.rst | 14 + > .../security/diglim/introduction.rst | 599 +++++++ > .../security/diglim/remote_attestation.rst | 87 + > Documentation/security/diglim/tests.rst | 70 + > Documentation/security/index.rst | 1 + > MAINTAINERS | 20 + > include/linux/diglim.h | 28 + > include/linux/kernel_read_file.h | 1 + > include/uapi/linux/diglim.h | 51 + > security/integrity/Kconfig | 1 + > security/integrity/Makefile | 1 + > security/integrity/diglim/Kconfig | 11 + > security/integrity/diglim/Makefile | 8 + > security/integrity/diglim/diglim.h | 232 +++ > security/integrity/diglim/fs.c | 865 ++++++++++ > security/integrity/diglim/ima.c | 122 ++ > security/integrity/diglim/methods.c | 513 ++++++ > security/integrity/diglim/parser.c | 274 ++++ > security/integrity/integrity.h | 4 + > tools/testing/selftests/Makefile | 1 + > tools/testing/selftests/diglim/Makefile | 19 + > tools/testing/selftests/diglim/common.c | 135 ++ > tools/testing/selftests/diglim/common.h | 32 + > tools/testing/selftests/diglim/config | 3 + > tools/testing/selftests/diglim/selftest.c | 1442 +++++++++++++++++ > 27 files changed, 4808 insertions(+) > create mode 100644 Documentation/security/diglim/architecture.rst > create mode 100644 Documentation/security/diglim/implementation.rst > create mode 100644 Documentation/security/diglim/index.rst > create mode 100644 Documentation/security/diglim/introduction.rst > create mode 100644 Documentation/security/diglim/remote_attestation.rst > create mode 100644 Documentation/security/diglim/tests.rst > create mode 100644 include/linux/diglim.h > create mode 100644 include/uapi/linux/diglim.h > create mode 100644 security/integrity/diglim/Kconfig > create mode 100644 security/integrity/diglim/Makefile > create mode 100644 security/integrity/diglim/diglim.h > create mode 100644 security/integrity/diglim/fs.c > create mode 100644 security/integrity/diglim/ima.c > create mode 100644 security/integrity/diglim/methods.c > create mode 100644 security/integrity/diglim/parser.c > create mode 100644 tools/testing/selftests/diglim/Makefile > create mode 100644 tools/testing/selftests/diglim/common.c > create mode 100644 tools/testing/selftests/diglim/common.h > create mode 100644 tools/testing/selftests/diglim/config > create mode 100644 tools/testing/selftests/diglim/selftest.c > > -- > 2.25.1
