| 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
| ||
|
Message-ID: <bc9521dd0412471e8e928110d7e0f11a@huawei.com>
Date: Thu, 28 Oct 2021 09:08:25 +0000
From: Roberto Sassu <roberto.sassu@...wei.com>
To: "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>
CC: "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 00/13] integrity: Introduce DIGLIM
> 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@...wei.com/)
> - support for the euid policy keyword for critical data
> (https://lore.kernel.org/linux-integrity/20210705115650.3373599-1-
> roberto.sassu@...wei.com/)
> - 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@...wei.com/
>
> 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@...wei.com/
> - 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
Powered by blists - more mailing lists