Searched refs:verified (Results 1 – 25 of 84) sorted by relevance
1234
| /Linux-v6.6/crypto/asymmetric_keys/ |
| D | pkcs7_trust.c | 40 if (x509->verified) in pkcs7_validate_trust_one()
41 goto verified; in pkcs7_validate_trust_one()
124 verified: in pkcs7_validate_trust_one()
126 x509->verified = true; in pkcs7_validate_trust_one()
128 p->verified = true; in pkcs7_validate_trust_one()
|
| D | x509_parser.h | 37 bool verified; member
|
| /Linux-v6.6/fs/verity/ |
| D | verify.c | 22 bool verified; in is_hash_block_verified() local
63 verified = test_bit(hblock_idx, vi->hash_block_verified); in is_hash_block_verified()
75 verified = false; in is_hash_block_verified()
78 return verified; in is_hash_block_verified()
|
| /Linux-v6.6/Documentation/admin-guide/device-mapper/ |
| D | verity.rst | 127 Hash blocks are still verified each time they are read from the hash device,
129 blocks, and a hash block will not be verified any more after all the data
130 blocks it covers have been verified anyway.
151 dm-verity is meant to be set up as part of a verified boot path. This
157 After instantiation, all hashes will be verified on-demand during
158 disk access. If they cannot be verified up to the root node of the
168 corrupted data will be verified using the cryptographic hash of the
210 the command-line is verified.
|
| /Linux-v6.6/Documentation/firmware-guide/acpi/ |
| D | chromeos-acpi-device.rst | 40 - Chrome OS verified boot data
284 - Offset in CMOS bank 0 of the verified boot non-volatile storage block, counting from
290 - Size in bytes of the verified boot non-volatile storage block.
306 VDTA (Chrome OS verified boot data)
308 This control method returns the verified boot data block shared between the firmware
317 A buffer containing the verified boot data block.
|
| /Linux-v6.6/tools/memory-model/scripts/ |
| D | checktheselitmus.sh | 41 echo All litmus tests verified as was expected. 1>&2
|
| D | checkalllitmus.sh | 63 echo All litmus tests verified as was expected. 1>&2
|
| /Linux-v6.6/Documentation/ABI/testing/ |
| D | sysfs-driver-chromeos-acpi | 132 Returns offset in CMOS bank 0 of the verified boot non-volatile
142 Return the size in bytes of the verified boot non-volatile
150 Returns the verified boot data block shared between the
|
| D | sysfs-class-chromeos-driver-cros-ec-vbc | 5 Read/write the verified boot context data included on a
|
| D | sysfs-firmware-ofw | 48 blob, and verified at late_initcall time. The sysfs
|
| /Linux-v6.6/Documentation/admin-guide/sysctl/ |
| D | user.rst | 26 verified to be below the per user limit in that user namespace.
30 in (user namespaces can be nested) and verified to be below the per user
|
| /Linux-v6.6/security/integrity/ima/ |
| D | Kconfig | 197 be signed and verified by a public key on the trusted IMA
200 Kernel image signatures can not be verified by the original
210 and verified by a public key on the trusted IMA keyring.
212 Kernel module signatures can only be verified by IMA-appraisal,
222 and verified by a key on the trusted IMA keyring.
|
| /Linux-v6.6/Documentation/w1/slaves/ |
| D | w1_ds2413.rst | 33 Bit 4-7: Complement of Bit 3 to Bit 0 (verified by the kernel module)
|
| /Linux-v6.6/Documentation/admin-guide/LSM/ |
| D | LoadPin.rst | 8 such as dm-verity or CDROM. This allows systems that have a verified
|
| /Linux-v6.6/drivers/firmware/google/ |
| D | Kconfig | 28 BIOS. These data structures expose things like the verified
|
| /Linux-v6.6/Documentation/networking/ |
| D | driver.rst | 14 be verified. For example, for ethernet check it with
|
| /Linux-v6.6/Documentation/arch/x86/ |
| D | shstk.rst | 44 An application's CET capability is marked in its ELF note and can be verified
138 verified and restored by the kernel. The kernel will also push the normal
|
| D | tdx.rst | 242 provided by attestation service so the TDREPORT can be verified uniquely.
248 by design can only be verified on the local platform as the MAC key is
|
| /Linux-v6.6/Documentation/bpf/ |
| D | verifier.rst | 393 defined by some instruction verified between this verifier state's parent and
578 Another point is the handling of read marks when a previously verified state is
580 as if the current state was verified to the program exit. This means that all
602 * Chain of states ``S -> A -> B -> exit`` is verified first.
604 * While ``B -> exit`` is verified, register ``r1`` is read and this read mark is
607 * When chain of states ``C -> D`` is verified the state ``D`` turns out to be
|
| D | prog_cgroup_sysctl.rst | 80 string value set by the helper is treated and verified by kernel same way as
|
| /Linux-v6.6/Documentation/driver-api/memory-devices/ |
| D | ti-gpmc.rst | 45 Generic timing routine has been verified to work properly on
|
| /Linux-v6.6/Documentation/arch/s390/ |
| D | driver-model.rst | 171 verified that the device is not already online.
185 verified that the device is online.
|
| /Linux-v6.6/fs/ext4/ |
| D | balloc.c | 417 goto verified; in ext4_validate_block_bitmap()
445 verified: in ext4_validate_block_bitmap()
|
| /Linux-v6.6/Documentation/filesystems/ |
| D | fsverity.rst | 26 automatically verified against the file's Merkle tree. Reads of any
572 fs-verity. In this case, the plaintext data is verified rather than
623 fs-verity ensures that all reads of a verity file's data are verified,
627 already verified). Below, we describe how filesystems implement this.
654 blocks until an already-verified hash block is seen. It then verifies
674 encrypted, the data must be decrypted before being verified. To
857 Uptodate until they've been verified. Currently, each
|
| D | xfs-self-describing-metadata.rst | 97 metadata block can be verified as being in the correct place without needing to
183 is extensively verified and if it is OK we then update the LSN from the last
346 inode is already extensively verified during writeback in xfs_iflush_int, so the
|
1234
