Home
last modified time | relevance | path

Searched refs:verified (Results 1 – 25 of 77) sorted by relevance

1234

/linux/crypto/asymmetric_keys/
H A Dpkcs7_trust.c40 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()
H A Dx509_parser.h38 bool verified; member
/linux/Documentation/firmware-guide/acpi/
H A Dchromeos-acpi-device.rst40 - 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/Documentation/admin-guide/device-mapper/
H A Dverity.rst136 Hash blocks are still verified each time they are read from the hash device,
138 blocks, and a hash block will not be verified any more after all the data
139 blocks it covers have been verified anyway.
167 dm-verity is meant to be set up as part of a verified boot path. This
173 After instantiation, all hashes will be verified on-demand during
174 disk access. If they cannot be verified up to the root node of the
184 corrupted data will be verified using the cryptographic hash of the
226 the command-line is verified.
/linux/Documentation/ABI/testing/
H A Dsysfs-driver-chromeos-acpi132 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
H A Dsysfs-class-chromeos-driver-cros-ec-vbc5 Read/write the verified boot context data included on a
H A Dsysfs-firmware-ofw48 blob, and verified at late_initcall time. The sysfs
/linux/drivers/md/dm-vdo/
H A Ddedupe.c244 bool verified; member
639 if (!lock->verified) { in finish_unlocking()
654 lock->verified = false; in finish_unlocking()
795 VDO_ASSERT_LOG_ONLY(lock->verified, "new advice should have been verified"); in start_updating()
1080 lock->verified = agent->is_duplicate; in finish_verifying()
1088 if (lock->verified) in finish_verifying()
1098 if (lock->verified && !vdo_claim_pbn_lock_increment(lock->duplicate_lock)) { in finish_verifying()
1100 lock->verified = false; in finish_verifying()
1103 if (lock->verified) { in finish_verifying()
1200 VDO_ASSERT_LOG_ONLY(!lock->verified, "hash lock only verifies advice once"); in start_verifying()
[all …]
/linux/tools/memory-model/scripts/
H A Dchecktheselitmus.sh41 echo All litmus tests verified as was expected. 1>&2
H A Dcheckalllitmus.sh63 echo All litmus tests verified as was expected. 1>&2
/linux/Documentation/admin-guide/sysctl/
H A Duser.rst26 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/security/integrity/ima/
H A DKconfig198 be signed and verified by a public key on the trusted IMA
201 Kernel image signatures can not be verified by the original
211 and verified by a public key on the trusted IMA keyring.
213 Kernel module signatures can only be verified by IMA-appraisal,
223 and verified by a key on the trusted IMA keyring.
/linux/Documentation/gpu/nova/core/
H A Dfalcon.rst34 the chip. The HS binary includes a signature in it which is verified at boot.
62 memory into the Falcon's IMEM/DMEM. Once the HS ucode is loaded, it is verified
65 Once the verified HS code is running on a Falcon, it can verify and load other
80 verified by the hardware and run, the CPU itself typically does not load
/linux/Documentation/w1/slaves/
H A Dw1_ds2413.rst33 Bit 4-7: Complement of Bit 3 to Bit 0 (verified by the kernel module)
/linux/Documentation/admin-guide/LSM/
H A DLoadPin.rst8 such as dm-verity or CDROM. This allows systems that have a verified
/linux/drivers/firmware/google/
H A DKconfig28 BIOS. These data structures expose things like the verified
/linux/Documentation/filesystems/
H A Dfsverity.rst26 automatically verified against the file's Merkle tree. Reads of any
95 files with a verified fs-verity's built-in signature. For
479 that contain a verified built-in fsverity signature.
515 files with a verified fs-verity builtin signature to perform certain
600 fs-verity. In this case, the plaintext data is verified rather than
651 fs-verity ensures that all reads of a verity file's data are verified,
655 already verified). Below, we describe how filesystems implement this.
682 blocks until an already-verified hash block is seen. It then verifies
702 encrypted, the data must be decrypted before being verified. To
885 Uptodate until they've been verified. Currently, each
/linux/Documentation/arch/x86/
H A Dshstk.rst44 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
/linux/Documentation/networking/
H A Ddriver.rst14 be verified. For example, for ethernet check it with
/linux/Documentation/security/tpm/
H A Dtpm-security.rst117 then be verified by certification in user-space. Therefore, this chain
170 certificate itself must be verified to chain back to the manufacturer
206 signature of the returned certifyInfo is verified against the public
/linux/Documentation/bpf/
H A Dverifier.rst393 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
H A Dprog_cgroup_sysctl.rst80 string value set by the helper is treated and verified by kernel same way as
/linux/Documentation/arch/s390/
H A Ddriver-model.rst171 verified that the device is not already online.
185 verified that the device is online.
/linux/Documentation/driver-api/memory-devices/
H A Dti-gpmc.rst45 Generic timing routine has been verified to work properly on
/linux/Documentation/filesystems/xfs/
H A Dxfs-self-describing-metadata.rst97 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