Searched full:verified (Results 1 – 25 of 75) sorted by relevance
123
| /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.
158 dm-verity is meant to be set up as part of a verified boot path. This
164 After instantiation, all hashes will be verified on-demand during
165 disk access. If they cannot be verified up to the root node of the
175 corrupted data will be verified using the cryptographic hash of the
217 the command-line is verified.
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-chromeos-driver-cros-ec-vbc | 5 Read/write the verified boot context data included on a
|
| 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-firmware-ofw | 48 blob, and verified at late_initcall time. The sysfs
|
| D | debugfs-driver-qat | 78 when performing verified compression.
|
| D | sysfs-driver-w1_therm | 63 actual resolution is read back from the chip and verified. Error
|
| /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.
|
| /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
|
| /Documentation/devicetree/bindings/arm/ |
| D | arm,corstone1000.yaml | 14 ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
|
| /Documentation/admin-guide/LSM/ |
| D | LoadPin.rst | 8 such as dm-verity or CDROM. This allows systems that have a verified
|
| /Documentation/devicetree/bindings/bus/ |
| D | st,stm32-etzpc.yaml | 70 // Access rights are verified before creating devices.
|
| D | st,stm32mp25-rifsc.yaml | 86 // Access rights are verified before creating devices.
|
| /Documentation/filesystems/ |
| D | fsverity.rst | 26 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
|
| /Documentation/security/tpm/ |
| D | tpm-security.rst | 117 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
|
| /Documentation/w1/slaves/ |
| D | w1_ds2413.rst | 33 Bit 4-7: Complement of Bit 3 to Bit 0 (verified by the kernel module)
|
| D | w1_therm.rst | 82 resolution is read back from the chip and verified.
|
| /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
|
| /Documentation/userspace-api/ |
| D | mfd_noexec.rst | 18 executables should come from the rootfs, which is protected by verified
|
| /Documentation/networking/ |
| D | driver.rst | 14 be verified. For example, for ethernet check it with
|
| /Documentation/driver-api/memory-devices/ |
| D | ti-gpmc.rst | 45 Generic timing routine has been verified to work properly on
|
| /Documentation/arch/s390/ |
| D | driver-model.rst | 171 verified that the device is not already online.
185 verified that the device is online.
|
| /Documentation/filesystems/xfs/ |
| 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
|
| /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
|
| /Documentation/i2c/ |
| D | fault-codes.rst | 108 have verified that functionality was supported before it
|
123