<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Android on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/android/</link><description>Recent content in Android on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/android/index.xml" rel="self" type="application/rss+xml"/><item><title>dm-verity</title><link>https://lesitedefrancois.be/en/security/dm-verity/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/dm-verity/</guid><description>&lt;p&gt;&lt;strong&gt;dm-verity&lt;/strong&gt; is a Linux device mapper target, available since kernel 3.4, that provides &lt;strong&gt;transparent read-only integrity verification&lt;/strong&gt; for block devices. When a block device is mapped through dm-verity, every data block read from the underlying device is verified against a pre-computed &lt;strong&gt;Merkle tree&lt;/strong&gt; of cryptographic hashes before being returned to the caller — any modification to any block, whether from corruption, bit rot, or deliberate tampering, produces a hash mismatch that dm-verity detects and handles according to its configured error mode. The verification is transparent to the filesystem and applications mounted above it: they read from the dm-verity device as if it were a normal block device, with no awareness that every read is being hash-checked. The security guarantee is that the integrity of the entire block device is committed to by a single &lt;strong&gt;root hash&lt;/strong&gt; — a 32-byte SHA-256 value that covers the entire Merkle tree and therefore the entire data volume. If the root hash is known to be correct (because it was measured into a &lt;strong&gt;TPM&lt;/strong&gt; PCR, embedded in a &lt;strong&gt;UKI&lt;/strong&gt;, or signed by a &lt;strong&gt;Secure Boot&lt;/strong&gt; key), then any verified read from the dm-verity device is guaranteed to return exactly the data that was present when the Merkle tree was computed.&lt;/p&gt;</description></item><item><title>fs-verity</title><link>https://lesitedefrancois.be/en/security/fs-verity/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/fs-verity/</guid><description>&lt;p&gt;&lt;strong&gt;fs-verity&lt;/strong&gt; is a Linux kernel filesystem feature, merged in kernel 5.4, that provides &lt;strong&gt;read-only, content-addressable integrity verification at the individual file level&lt;/strong&gt;. When fs-verity is enabled on a file (via the &lt;code&gt;FS_IOC_ENABLE_VERITY&lt;/code&gt; ioctl), the kernel builds a &lt;strong&gt;Merkle tree&lt;/strong&gt; of the file&amp;rsquo;s content blocks and stores it in a filesystem-specific location (in an ext4 or f2fs Merkle tree block range, or in a separate xattr-adjacent structure on btrfs). From that point, the file becomes immutable — writes are rejected — and every page read from the file is verified against the Merkle tree before being returned to userspace. The file&amp;rsquo;s &lt;strong&gt;fs-verity digest&lt;/strong&gt; is the SHA-256 (or SHA-512) root hash of the Merkle tree, computable without reading the file at all once the tree is built: &lt;code&gt;fsverity digest file&lt;/code&gt; returns this digest. A file&amp;rsquo;s fs-verity digest is a stable, content-derived identity: two files with the same content have the same digest, and any byte-level modification produces a different digest that verification will detect and reject with &lt;code&gt;EIO&lt;/code&gt;. The kernel caches verified Merkle tree nodes in the page cache alongside file data, so the amortised verification overhead is low for sequentially-read files.&lt;/p&gt;</description></item></channel></rss>