Lines Matching full:file
6 fs-verity: read-only file-based authenticity protection
22 causes the filesystem to build a Merkle tree for the file and persist
23 it to a filesystem-specific location associated with the file.
25 After this, the file is made readonly, and all reads from the file are
26 automatically verified against the file's Merkle tree. Reads of any
30 the "fs-verity file digest", which is a hash that includes the Merkle
31 tree root hash) that fs-verity is enforcing for the file. This ioctl
32 executes in constant time, regardless of the file size.
34 fs-verity is essentially a way to hash a file in constant time,
44 However, because fs-verity makes retrieving the file hash extremely
47 (logging file hashes before use).
51 authenticate the contents of an fs-verity file by using the
55 A standard file hash could be used instead of fs-verity. However,
56 this is inefficient if the file is large and only a small portion may
61 read and hash the entire file before starting the application.
65 undetectably change the contents of the file at runtime.
77 `Built-in signature verification`_. Support for fs-verity file hashes
86 The FS_IOC_ENABLE_VERITY ioctl enables fs-verity on a file. It takes
103 the file, and optionally contains a signature. It must be initialized
117 file or device. Currently the maximum salt size is 32 bytes.
129 the file and persist it to a filesystem-specific location associated
130 with the file, then mark the file as a verity file. This ioctl may
135 it must be executed on an O_RDONLY file descriptor and no processes
136 can have the file open for writing. Attempts to open the file for
138 is necessary to guarantee that no writable file descriptors will exist
139 after verity is enabled, and to guarantee that the file's contents are
142 On success, FS_IOC_ENABLE_VERITY returns 0, and the file becomes a
143 verity file. On failure (including the case of interruption by a
144 fatal signal), no changes are made to the file.
148 - ``EACCES``: the process does not have write access to the file
150 - ``EBUSY``: this ioctl is already running on the file
151 - ``EEXIST``: the file already has verity enabled
155 reserved bits are set; or the file descriptor refers to neither a
156 regular file nor a directory.
157 - ``EISDIR``: the file descriptor refers to a directory
158 - ``EKEYREJECTED``: the signature doesn't match the file
169 on this file. (See `Filesystem support`_.)
170 - ``EPERM``: the file is append-only; or, a signature is required and
173 - ``ETXTBSY``: someone has the file open for writing. This can be the
174 caller's file descriptor, another open file descriptor, or the file
180 The FS_IOC_MEASURE_VERITY ioctl retrieves the digest of a verity file.
181 The fs-verity file digest is a cryptographic digest that identifies
182 the file contents that are being enforced on reads; it is computed via
183 a Merkle tree and is different from a traditional full-file digest.
200 - ``digest_algorithm`` will be the hash algorithm used for the file
207 regardless of the size of the file.
212 - ``ENODATA``: the file is not a verity file
224 verity file. This ioctl is available since Linux v5.12.
226 This ioctl allows writing a server program that takes a verity file
228 fs-verity compatible verification of the file. This only makes sense
274 to be authenticated against the file digest that would be returned by
287 - ``ENODATA``: the file is not a verity file, or
288 FS_VERITY_METADATA_TYPE_SIGNATURE was requested but the file doesn't
300 can also be used to check whether a file has fs-verity enabled or not.
310 the file has fs-verity enabled. This can perform better than
312 opening the file, and opening verity files can be expensive.
317 Applications can transparently access a verity file just like a
321 truncate()d, even if the file mode bits allow it. Attempts to do
337 file is not signed by a key in the fs-verity keyring, then opening
338 the file will fail. See `Built-in signature verification`_.
341 verity file is copied, or is backed up and restored, then it will lose
345 File digest computation
348 This section describes how fs-verity hashes the file contents using a
350 the file contents. This algorithm is the same for all filesystems
354 compute fs-verity file digests itself, e.g. in order to sign files.
361 The file contents is divided into blocks, where the block size is
370 If the file fits in one block and is nonempty, then the "Merkle tree
371 root hash" is simply the hash of the single data block. If the file
391 the original file size. However, for small files, the padding is
400 can't a distinguish a large file from a small second file whose data
401 is exactly the top-level hash block of the first file. Ambiguities
404 To solve this problem, the fs-verity file digest is actually computed
406 root hash as well as other fields such as the file size::
414 __le64 data_size; /* size of file the Merkle tree is built over */
434 detached signature in DER format of the file's fs-verity digest.
436 Then, any time the file is opened, the kernel will verify the
437 file's actual digest against this signature, using the certificates
444 fs-verity file digests must be signed in the following format, which
475 ``fs/verity/`` at certain times, such as when a file is opened or when
496 the ciphertext. This is necessary in order to make the fs-verity file
497 digest meaningful, since every file is encrypted differently.
500 past the end of the file, starting at the first 64K boundary beyond
508 when the file is, since it contains hashes of the plaintext data.
527 fsverity_descriptor) past the end of the file, starting at the first
542 fs-verity ensures that all reads of a verity file's data are verified,
566 read() from the part of the file containing the page will fail with
590 also usually read many pages from a file at once, grouped into a
595 ext4 and f2fs also support encryption. If a verity file is also
631 See the README.md file in the fsverity-utils source tree for details,
657 alternative to doing full file hashes, for people who want the
666 :A: To verify the authenticity of an fs-verity file you must verify
667 the authenticity of the "fs-verity file digest", which
671 verity file with a non-verity one?
680 compute the entire tree when the file is first accessed, even if
686 children, and so on until you've actually hashed the entire file.
689 since if you have to hash the whole file ahead of time anyway,
690 then you could simply do sha256(file) instead. That would be much
728 (especially of potentially the entire file!) is unacceptable.
750 specific set of semantics which not only make the file contents
751 read-only, but also prevent the file from being deleted, renamed,
764 principle any filesystem that can store per-file verity metadata
768 the file and "hide" it from userspace by manipulating i_size. The
791 file contents are, because it stores hashes of the plaintext
792 file contents.
795 file. Using a separate file would be very ugly, since the
796 metadata is fundamentally part of the file to be protected, and
797 it could cause problems where users could delete the real file
798 but not the metadata file or vice versa. On the other hand,
799 having it be in the same file would break applications unless
804 transaction mechanism so that either the file ends up with