Home
last modified time | relevance | path

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

1234

/linux/crypto/asymmetric_keys/
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()
A Dx509_parser.h38 bool verified; member
/linux/Documentation/admin-guide/device-mapper/
A Dverity.rst127 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/Documentation/firmware-guide/acpi/
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/tools/memory-model/scripts/
A Dchecktheselitmus.sh41 echo All litmus tests verified as was expected. 1>&2
A Dcheckalllitmus.sh63 echo All litmus tests verified as was expected. 1>&2
/linux/Documentation/ABI/testing/
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
A Dsysfs-class-chromeos-driver-cros-ec-vbc5 Read/write the verified boot context data included on a
A Dsysfs-firmware-ofw48 blob, and verified at late_initcall time. The sysfs
/linux/drivers/md/dm-vdo/
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()
1100 lock->verified = false; in finish_verifying()
1103 if (lock->verified) { in finish_verifying()
1246 if (!lock->verified) { in finish_locking()
1263 lock->verified = false; in finish_locking()
[all …]
/linux/Documentation/admin-guide/sysctl/
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/
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/drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/arch/nvalloc/common/inc/gsp/
A Dgsp_fw_wpr_meta.h164 NvU64 verified; // 0x0 -> unverified, 0xa0a0a0a0a0a0a0a0 -> verified member
/linux/Documentation/devicetree/bindings/arm/
A Darm,corstone1000.yaml14 ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
/linux/Documentation/devicetree/bindings/bus/
A Dst,stm32-etzpc.yaml70 // Access rights are verified before creating devices.
A Dst,stm32mp25-rifsc.yaml86 // Access rights are verified before creating devices.
/linux/Documentation/w1/slaves/
A Dw1_ds2413.rst33 Bit 4-7: Complement of Bit 3 to Bit 0 (verified by the kernel module)
/linux/Documentation/admin-guide/LSM/
A DLoadPin.rst8 such as dm-verity or CDROM. This allows systems that have a verified
/linux/drivers/firmware/google/
A DKconfig28 BIOS. These data structures expose things like the verified
/linux/Documentation/networking/
A Ddriver.rst14 be verified. For example, for ethernet check it with
/linux/Documentation/arch/x86/
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/filesystems/
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
474 that contain a verified built-in fsverity signature.
510 files with a verified fs-verity builtin signature to perform certain
595 fs-verity. In this case, the plaintext data is verified rather than
646 fs-verity ensures that all reads of a verity file's data are verified,
650 already verified). Below, we describe how filesystems implement this.
677 blocks until an already-verified hash block is seen. It then verifies
697 encrypted, the data must be decrypted before being verified. To
880 Uptodate until they've been verified. Currently, each
/linux/Documentation/userspace-api/
A Dmfd_noexec.rst18 executables should come from the rootfs, which is protected by verified
/linux/Documentation/security/tpm/
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/
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

Completed in 45 milliseconds

1234