1 .. SPDX-License-Identifier: GPL-2.0
2
3 Integrity Policy Enforcement (IPE)
4 ==================================
5
6 .. NOTE::
7
8 This is the documentation for admins, syste
9 attempting to use IPE. If you're looking fo
10 documentation about IPE please see :doc:`th
11
12 Overview
13 --------
14
15 Integrity Policy Enforcement (IPE) is a Linux
16 complementary approach to access control. Unli
17 mechanisms that rely on labels and paths for d
18 on the immutable security properties inherent
19 properties are fundamental attributes or featu
20 that cannot be altered, ensuring a consistent
21 security decisions.
22
23 To elaborate, in the context of IPE, system co
24 files or the devices these files reside on. Ho
25 starting point. The concept of system componen
26 extended to include new elements as the system
27 properties include the origin of a file, which
28 unchangeable over time. For example, IPE polic
29 files originating from the initramfs. Since in
30 by the bootloader, its files are deemed trustw
31 initramfs" becomes an immutable property under
32
33 The immutable property concept extends to the
34 a file's origin, such as dm-verity or fs-verit
35 integrity and trust. For example, IPE allows t
36 that trust files from a dm-verity protected de
37 integrity of an entire device by providing a v
38 of its contents. Similarly, fs-verity offers f
39 checks, allowing IPE to enforce policies that
40 fs-verity. These two features cannot be turned
41 they are considered immutable properties. Thes
42 IPE leverages immutable properties, such as a
43 integrity protection mechanisms, to make acces
44
45 For the IPE policy, specifically, it grants th
46 stringent access controls by assessing securit
47 reference values defined within the policy. Th
48 the existence of a security property (e.g., ve
49 from initramfs) or evaluating the internal sta
50 property. The latter includes checking the roo
51 protected device, determining whether dm-verit
52 signature, assessing the digest of a fs-verity
53 determining whether fs-verity possesses a vali
54 nuanced approach to policy enforcement enables
55 customizable system defense mechanism, tailore
56 requirements and trust models.
57
58 To enable IPE, ensure that ``CONFIG_SECURITY_I
59 :menuselection:`Security -> Integrity Policy E
60 option is enabled.
61
62 Use Cases
63 ---------
64
65 IPE works best in fixed-function devices: devi
66 is clearly defined and not supposed to be chan
67 device in a data center, an IoT device, etcete
68 configuration is built and provisioned by the
69
70 IPE is a long-way off for use in general-purpo
71 community as a whole tends to follow a decentr
72 the web of trust), which IPE has no support fo
73 supports PKI (public key infrastructure), whic
74 set of trusted entities that provide a measure
75
76 Additionally, while most packages are signed t
77 the packages (for instance, the executables),
78 makes it difficult to utilize IPE in systems w
79 expected to be functional, without major chang
80 and ecosystem behind it.
81
82 The digest_cache LSM [#digest_cache_lsm]_ is a
83 could be used to enable and support general-pu
84
85 Known Limitations
86 -----------------
87
88 IPE cannot verify the integrity of anonymous e
89 the trampolines created by gcc closures and li
90 Unfortunately, as this is dynamically generate
91 for IPE to ensure the integrity of this code t
92
93 IPE cannot verify the integrity of programs wr
94 languages when these scripts are invoked by pa
95 to the interpreter. This is because the way in
96 files; the scripts themselves are not evaluate
97 through one of IPE's hooks, but they are merel
98 (as opposed to compiled executables) [#interpr
99
100 Threat Model
101 ------------
102
103 IPE specifically targets the risk of tampering
104 code after the kernel has initially booted, in
105 loaded from userspace via ``modprobe`` or ``in
106
107 To illustrate, consider a scenario where an un
108 malicious, is downloaded along with all necess
109 loader and libc. The primary function of IPE i
110 the execution of such binaries and their depen
111
112 IPE achieves this by verifying the integrity a
113 executable code before allowing them to run. I
114 check to ensure that the code's integrity is i
115 authorized reference value (digest, signature,
116 policy. If a binary does not pass this verific
117 because its integrity has been compromised or
118 authorization criteria, IPE will deny its exec
119 generates audit logs which may be utilized to
120 resulting from policy violation.
121
122 Tampering threat scenarios include modificatio
123 executable code by a range of actors including
124
125 - Actors with physical access to the hardware
126 - Actors with local network access to the sys
127 - Actors with access to the deployment system
128 - Compromised internal systems under external
129 - Malicious end users of the system
130 - Compromised end users of the system
131 - Remote (external) compromise of the system
132
133 IPE does not mitigate threats arising from mal
134 developers (with access to a signing certifica
135 developer tools used by them (i.e. return-orie
136 Additionally, IPE draws hard security boundary
137 kernelspace. As a result, kernel-level exploit
138 the scope of IPE and mitigation is left to oth
139
140 Policy
141 ------
142
143 IPE policy is a plain-text [#devdoc]_ policy c
144 over several lines. There is one required line
145 policy, indicating the policy name, and the po
146 instance::
147
148 policy_name=Ex_Policy policy_version=0.0.0
149
150 The policy name is a unique key identifying th
151 readable name. This is used to create nodes un
152 uniquely identify policies to deploy new polic
153 policies.
154
155 The policy version indicates the current versi
156 policy syntax version). This is used to preven
157 potentially insecure previous versions of the
158
159 The next portion of IPE policy are rules. Rule
160 pairs, known as properties. IPE rules require
161 which determines what IPE does when it encount
162 rule, and ``op``, which determines when the ru
163 The ordering is significant, a rule must start
164 ``action``. Thus, a minimal rule is::
165
166 op=EXECUTE action=ALLOW
167
168 This example will allow any execution. Additio
169 assess immutable security properties about the
170 These properties are intended to be descriptio
171 kernel that can provide a measure of integrity
172 can determine the trust of the resource based
173
174 Rules are evaluated top-to-bottom. As a result
175 or denies should be placed early in the file t
176 are evaluated before a rule with ``action=ALLO
177
178 IPE policy supports comments. The character '#
179 comment, ignoring all characters to the right
180
181 The default behavior of IPE evaluations can al
182 through the ``DEFAULT`` statement. This can be
183 or a per-operation level::
184
185 # Global
186 DEFAULT action=ALLOW
187
188 # Operation Specific
189 DEFAULT op=EXECUTE action=ALLOW
190
191 A default must be set for all known operations
192 preserve older policies being compatible with
193 new operations, set a global default of ``ALLO
194 defaults on a per-operation basis (as above).
195
196 With configurable policy-based LSMs, there's s
197 enforcing the configurable policies at startup
198 parsing the policy:
199
200 1. The kernel *should* not read files from use
201 the policy file is prohibited.
202 2. The kernel command line has a character lim
203 should not reserve the entire character lim
204 configuration.
205 3. There are various boot loaders in the kerne
206 off a memory block would be costly to maint
207
208 As a result, IPE has addressed this problem th
209 policy". A boot policy is a minimal policy whi
210 kernel. This policy is intended to get the sys
211 userspace is set up and ready to receive comma
212 complex policy can be deployed via securityfs.
213 specified via ``SECURITY_IPE_BOOT_POLICY`` con
214 a path to a plain-text version of the IPE poli
215 will be compiled into the kernel. If not speci
216 until a policy is deployed and activated throu
217
218 Deploying Policies
219 ~~~~~~~~~~~~~~~~~~
220
221 Policies can be deployed from userspace throug
222 are signed through the PKCS#7 message format t
223 authorization of the policies (prohibiting an
224 unconstrained root, and deploying an "allow al
225 policies must be signed by a certificate that
226 ``SYSTEM_TRUSTED_KEYRING``, or to the secondar
227 ``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` an
228 ``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are
229 With openssl, the policy can be signed by::
230
231 openssl smime -sign \
232 -in "$MY_POLICY" \
233 -signer "$MY_CERTIFICATE" \
234 -inkey "$MY_PRIVATE_KEY" \
235 -noattr \
236 -nodetach \
237 -nosmimecap \
238 -outform der \
239 -out "$MY_POLICY.p7b"
240
241 Deploying the policies is done through securit
242 ``new_policy`` node. To deploy a policy, simpl
243 securityfs node::
244
245 cat "$MY_POLICY.p7b" > /sys/kernel/security
246
247 Upon success, this will create one subdirector
248 ``/sys/kernel/security/ipe/policies/``. The su
249 ``policy_name`` field of the policy deployed,
250 the directory will be ``/sys/kernel/security/i
251 Within this directory, there will be seven fil
252 ``name``, ``version``, ``active``, ``update``,
253
254 The ``pkcs7`` file is read-only. Reading it re
255 that was provided to the kernel, representing
256 read is the boot policy, this will return ``EN
257
258 The ``policy`` file is read only. Reading it r
259 content of the policy, which will be the plain
260
261 The ``active`` file is used to set a policy as
262 This file is rw, and accepts a value of ``"1"`
263 Since only a single policy can be active at on
264 will be marked inactive. The policy being mark
265 version greater or equal to the currently-runn
266
267 The ``update`` file is used to update a policy
268 in the kernel. This file is write-only and acc
269 policy. Two checks will always be performed on
270 ``policy_names`` must match with the updated v
271 version. Second the updated policy must have a
272 the currently-running version. This is to prev
273
274 The ``delete`` file is used to remove a policy
275 This file is write-only and accepts a value of
276 On deletion, the securityfs node representing
277 However, delete the current active policy is n
278 an operation not permitted error.
279
280 Similarly, writing to both ``update`` and ``ne
281 bad message(policy syntax error) or file exist
282 when trying to deploy a policy with a ``policy
283 has a deployed policy with the same ``policy_n
284
285 Deploying a policy will *not* cause IPE to sta
286 only enforce the policy marked active. Note th
287 at a time.
288
289 Once deployment is successful, the policy can
290 ``/sys/kernel/security/ipe/policies/$policy_na
291 For example, the ``Ex_Policy`` can be activate
292
293 echo 1 > "/sys/kernel/security/ipe/policies
294
295 From above point on, ``Ex_Policy`` is now the
296 system.
297
298 IPE also provides a way to delete policies. Th
299 ``delete`` securityfs node,
300 ``/sys/kernel/security/ipe/policies/$policy_na
301 Writing ``1`` to that file deletes the policy:
302
303 echo 1 > "/sys/kernel/security/ipe/policies
304
305 There is only one requirement to delete a poli
306 must be inactive.
307
308 .. NOTE::
309
310 If a traditional MAC system is enabled (SEL
311 writes to ipe's securityfs nodes require ``
312
313 Modes
314 ~~~~~
315
316 IPE supports two modes of operation: permissiv
317 permissive mode) and enforced. In permissive m
318 checked and policy violations are logged, but
319 enforced. This allows users to test policies b
320
321 The default mode is enforce, and can be change
322 line parameter ``ipe.enforce=(0|1)``, or the s
323 ``/sys/kernel/security/ipe/enforce``.
324
325 .. NOTE::
326
327 If a traditional MAC system is enabled (SEL
328 all writes to ipe's securityfs nodes requir
329
330 Audit Events
331 ~~~~~~~~~~~~
332
333 1420 AUDIT_IPE_ACCESS
334 ^^^^^^^^^^^^^^^^^^^^^
335 Event Examples::
336
337 type=1420 audit(1653364370.067:61): ipe_op=
338 type=1300 audit(1653364370.067:61): SYSCALL
339 type=1327 audit(1653364370.067:61): 7079746
340
341 type=1420 audit(1653364735.161:64): ipe_op=
342 type=1300 audit(1653364735.161:64): SYSCALL
343 type=1327 audit(1653364735.161:64): 7079746
344
345 This event indicates that IPE made an access c
346 specific record (1420) is always emitted in co
347 ``AUDITSYSCALL`` record.
348
349 Determining whether IPE is in permissive or en
350 from ``success`` property and exit code of the
351
352
353 Field descriptions:
354
355 +-----------+------------+-----------+--------
356 | Field | Value Type | Optional? | Descrip
357 +===========+============+===========+========
358 | ipe_op | string | No | The IPE
359 +-----------+------------+-----------+--------
360 | ipe_hook | string | No | The nam
361 +-----------+------------+-----------+--------
362 | enforcing | integer | No | The cur
363 +-----------+------------+-----------+--------
364 | pid | integer | No | The pid
365 +-----------+------------+-----------+--------
366 | comm | string | No | The com
367 +-----------+------------+-----------+--------
368 | path | string | Yes | The abs
369 +-----------+------------+-----------+--------
370 | ino | integer | Yes | The ino
371 +-----------+------------+-----------+--------
372 | dev | string | Yes | The dev
373 +-----------+------------+-----------+--------
374 | rule | string | No | The mat
375 +-----------+------------+-----------+--------
376
377 1421 AUDIT_IPE_CONFIG_CHANGE
378 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
379
380 Event Example::
381
382 type=1421 audit(1653425583.136:54): old_act
383 type=1300 audit(1653425583.136:54): SYSCALL
384 type=1327 audit(1653425583.136:54): PROCTIT
385
386 This event indicates that IPE switched the act
387 along with the version and the hash digest of
388 Note IPE can only have one policy active at a
389 evaluation is based on the current active poli
390 The normal procedure to deploy a new policy is
391 into the kernel first, then switch the active
392
393 This record will always be emitted in conjunct
394
395 Field descriptions:
396
397 +------------------------+------------+-------
398 | Field | Value Type | Option
399 +========================+============+=======
400 | old_active_pol_name | string | Yes
401 +------------------------+------------+-------
402 | old_active_pol_version | string | Yes
403 +------------------------+------------+-------
404 | old_policy_digest | string | Yes
405 +------------------------+------------+-------
406 | new_active_pol_name | string | No
407 +------------------------+------------+-------
408 | new_active_pol_version | string | No
409 +------------------------+------------+-------
410 | new_policy_digest | string | No
411 +------------------------+------------+-------
412 | auid | integer | No
413 +------------------------+------------+-------
414 | ses | integer | No
415 +------------------------+------------+-------
416 | lsm | string | No
417 +------------------------+------------+-------
418 | res | integer | No
419 +------------------------+------------+-------
420
421 1422 AUDIT_IPE_POLICY_LOAD
422 ^^^^^^^^^^^^^^^^^^^^^^^^^^
423
424 Event Example::
425
426 type=1422 audit(1653425529.927:53): policy_
427 type=1300 audit(1653425529.927:53): arch=c0
428 type=1327 audit(1653425529.927:53): PROCTIT
429
430 This record indicates a new policy has been lo
431
432 This record will always be emitted in conjunct
433
434 Field descriptions:
435
436 +----------------+------------+-----------+---
437 | Field | Value Type | Optional? | De
438 +================+============+===========+===
439 | policy_name | string | No | Th
440 +----------------+------------+-----------+---
441 | policy_version | string | No | Th
442 +----------------+------------+-----------+---
443 | policy_digest | string | No | Th
444 +----------------+------------+-----------+---
445 | auid | integer | No | Th
446 +----------------+------------+-----------+---
447 | ses | integer | No | Th
448 +----------------+------------+-----------+---
449 | lsm | string | No | Th
450 +----------------+------------+-----------+---
451 | res | integer | No | Th
452 +----------------+------------+-----------+---
453
454
455 1404 AUDIT_MAC_STATUS
456 ^^^^^^^^^^^^^^^^^^^^^
457
458 Event Examples::
459
460 type=1404 audit(1653425689.008:55): enforci
461 type=1300 audit(1653425689.008:55): arch=c0
462 type=1327 audit(1653425689.008:55): proctit
463
464 type=1404 audit(1653425689.008:55): enforci
465 type=1300 audit(1653425689.008:55): arch=c0
466 type=1327 audit(1653425689.008:55): proctit
467
468 This record will always be emitted in conjunct
469
470 Field descriptions:
471
472 +---------------+------------+-----------+----
473 | Field | Value Type | Optional? | Des
474 +===============+============+===========+====
475 | enforcing | integer | No | The
476 +---------------+------------+-----------+----
477 | old_enforcing | integer | No | The
478 +---------------+------------+-----------+----
479 | auid | integer | No | The
480 +---------------+------------+-----------+----
481 | ses | integer | No | The
482 +---------------+------------+-----------+----
483 | enabled | integer | No | The
484 +---------------+------------+-----------+----
485 | old-enabled | integer | No | The
486 +---------------+------------+-----------+----
487 | lsm | string | No | The
488 +---------------+------------+-----------+----
489 | res | integer | No | The
490 +---------------+------------+-----------+----
491
492
493 Success Auditing
494 ^^^^^^^^^^^^^^^^
495
496 IPE supports success auditing. When enabled, a
497 policy and are not blocked will emit an audit
498 default, and can be enabled via the kernel com
499 ``ipe.success_audit=(0|1)`` or
500 ``/sys/kernel/security/ipe/success_audit`` sec
501
502 This is *very* noisy, as IPE will check every
503 system, but is useful for debugging policies.
504
505 .. NOTE::
506
507 If a traditional MAC system is enabled (SEL
508 all writes to ipe's securityfs nodes requir
509
510 Properties
511 ----------
512
513 As explained above, IPE properties are ``key=v
514 policy. Two properties are built-into the poli
515 The other properties are used to restrict immu
516 about the files being evaluated. Currently tho
517 '``boot_verified``', '``dmverity_signature``',
518 '``fsverity_signature``', '``fsverity_digest``
519 properties supported by IPE are listed below:
520
521 op
522 ~~
523
524 Indicates the operation for a rule to apply to
525 as the first token. IPE supports the following
526
527 ``EXECUTE``
528
529 Pertains to any file attempting to be ex
530 executable.
531
532 ``FIRMWARE``:
533
534 Pertains to firmware being loaded via th
535 This covers both the preallocated buffer
536 itself.
537
538 ``KMODULE``:
539
540 Pertains to loading kernel modules via `
541
542 ``KEXEC_IMAGE``:
543
544 Pertains to kernel images loading via ``
545
546 ``KEXEC_INITRAMFS``
547
548 Pertains to initrd images loading via ``
549
550 ``POLICY``:
551
552 Controls loading policies via reading a
553
554 An example of such is loading IMA polici
555 to the policy file to ``$securityfs/ima/
556
557 ``X509_CERT``:
558
559 Controls loading IMA certificates throug
560 ``CONFIG_IMA_X509_PATH`` and ``CONFIG_EV
561
562 action
563 ~~~~~~
564
565 Determines what IPE should do when a rule m
566 rule, as the final clause. Can be one of:
567
568 ``ALLOW``:
569
570 If the rule matches, explicitly allow ac
571 without executing any more rules.
572
573 ``DENY``:
574
575 If the rule matches, explicitly prohibit
576 proceed without executing any more rules
577
578 boot_verified
579 ~~~~~~~~~~~~~
580
581 This property can be utilized for authoriza
582 The format of this property is::
583
584 boot_verified=(TRUE|FALSE)
585
586
587 .. WARNING::
588
589 This property will trust files from init
590 only be used during early booting stage.
591 rootfs on top of the initramfs, initramf
592 remove all files and directories on the
593 implemented by using switch_root(8) [#sw
594 initramfs will be empty and not accessib
595 rootfs takes over. It is advised to swit
596 that doesn't rely on the property after
597 This ensures that the trust policies rem
598 throughout the system's operation.
599
600 dmverity_roothash
601 ~~~~~~~~~~~~~~~~~
602
603 This property can be utilized for authoriza
604 specific dm-verity volumes, identified via
605 dependency on the DM_VERITY module. This pr
606 the ``IPE_PROP_DM_VERITY`` config option, i
607 selected when ``SECURITY_IPE`` and ``DM_VER
608 The format of this property is::
609
610 dmverity_roothash=DigestName:Hexadecimal
611
612 The supported DigestNames for dmverity_root
613
614 + blake2b-512
615 + blake2s-256
616 + sha256
617 + sha384
618 + sha512
619 + sha3-224
620 + sha3-256
621 + sha3-384
622 + sha3-512
623 + sm3
624 + rmd160
625
626 dmverity_signature
627 ~~~~~~~~~~~~~~~~~~
628
629 This property can be utilized for authoriza
630 volumes that have a signed roothash that va
631 specified by dm-verity's configuration, eit
632 keyring, or the secondary keyring. It depen
633 ``DM_VERITY_VERIFY_ROOTHASH_SIG`` config op
634 the ``IPE_PROP_DM_VERITY_SIGNATURE`` config
635 selected when ``SECURITY_IPE``, ``DM_VERITY
636 ``DM_VERITY_VERIFY_ROOTHASH_SIG`` are all e
637 The format of this property is::
638
639 dmverity_signature=(TRUE|FALSE)
640
641 fsverity_digest
642 ~~~~~~~~~~~~~~~
643
644 This property can be utilized for authoriza
645 enabled files, identified via their fsverit
646 It depends on ``FS_VERITY`` config option a
647 the ``IPE_PROP_FS_VERITY`` config option, i
648 selected when ``SECURITY_IPE`` and ``FS_VER
649 The format of this property is::
650
651 fsverity_digest=DigestName:HexadecimalSt
652
653 The supported DigestNames for fsverity_dige
654
655 + sha256
656 + sha512
657
658 fsverity_signature
659 ~~~~~~~~~~~~~~~~~~
660
661 This property is used to authorize all fs-v
662 been verified by fs-verity's built-in signa
663 verification relies on a key stored within
664 depends on ``FS_VERITY_BUILTIN_SIGNATURES``
665 it is controlled by the ``IPE_PROP_FS_VERIT
666 it will be automatically selected when ``SE
667 and ``FS_VERITY_BUILTIN_SIGNATURES`` are al
668 The format of this property is::
669
670 fsverity_signature=(TRUE|FALSE)
671
672 Policy Examples
673 ---------------
674
675 Allow all
676 ~~~~~~~~~
677
678 ::
679
680 policy_name=Allow_All policy_version=0.0.0
681 DEFAULT action=ALLOW
682
683 Allow only initramfs
684 ~~~~~~~~~~~~~~~~~~~~
685
686 ::
687
688 policy_name=Allow_Initramfs policy_version=
689 DEFAULT action=DENY
690
691 op=EXECUTE boot_verified=TRUE action=ALLOW
692
693 Allow any signed and validated dm-verity volum
694 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
695
696 ::
697
698 policy_name=Allow_Signed_DMV_And_Initramfs
699 DEFAULT action=DENY
700
701 op=EXECUTE boot_verified=TRUE action=ALLOW
702 op=EXECUTE dmverity_signature=TRUE action=A
703
704 Prohibit execution from a specific dm-verity v
705 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
706
707 ::
708
709 policy_name=Deny_DMV_By_Roothash policy_ver
710 DEFAULT action=DENY
711
712 op=EXECUTE dmverity_roothash=sha256:cd2c5ba
713
714 op=EXECUTE boot_verified=TRUE action=ALLOW
715 op=EXECUTE dmverity_signature=TRUE action=A
716
717 Allow only a specific dm-verity volume
718 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
719
720 ::
721
722 policy_name=Allow_DMV_By_Roothash policy_ve
723 DEFAULT action=DENY
724
725 op=EXECUTE dmverity_roothash=sha256:401fcec
726
727 Allow any fs-verity file with a valid built-in
728 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
729
730 ::
731
732 policy_name=Allow_Signed_And_Validated_FSVe
733 DEFAULT action=DENY
734
735 op=EXECUTE fsverity_signature=TRUE action=A
736
737 Allow execution of a specific fs-verity file
738 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
739
740 ::
741
742 policy_name=ALLOW_FSV_By_Digest policy_vers
743 DEFAULT action=DENY
744
745 op=EXECUTE fsverity_digest=sha256:fd88f2b88
746
747 Additional Information
748 ----------------------
749
750 - `Github Repository <https://github.com/micro
751 - :doc:`Developer and design docs for IPE </se
752
753 FAQ
754 ---
755
756 Q:
757 What's the difference between other LSMs wh
758 trust-based access control?
759
760 A:
761
762 In general, there's two other LSMs that can
763 IMA, and Loadpin.
764
765 IMA and IPE are functionally very similar.
766 the two is the policy. [#devdoc]_
767
768 Loadpin and IPE differ fairly dramatically,
769 kernel read operations, whereas IPE is capa
770 on top of kernel read. The trust model is a
771 trust in the initial super-block, whereas t
772 itself (via ``SYSTEM_TRUSTED_KEYS``).
773
774 -----------
775
776 .. [#digest_cache_lsm] https://lore.kernel.org
777
778 .. [#interpreters] There is `some interest in <
779
780 .. [#devdoc] Please see :doc:`the design docs
781 this topic.
782
783 .. [#switch_root] https://man7.org/linux/man-p
784
785 .. [#dmveritydigests] These hash algorithms ar
786 the Linux crypto API; IP
787 restrictions on the dige
788 thus, this list may be o
789
790 .. [#fsveritydigest] These hash algorithms are
791 kernel's fsverity support
792 restrictions on the diges
793 thus, this list may be ou
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.