--- title: Recent Developments Part III | daily.dev description: A GNOME developer describes building a full virtual test lab for hardware-wrapped storage encryption across the Linux stack, aimed at enabling GNOME OS to run... canonical: https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Recent Developments Part III | daily.dev og:description: A GNOME developer describes building a full virtual test lab for hardware-wrapped storage encryption across the Linux stack, aimed at enabling GNOME OS to run... og:url: https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv og:image: https://api.daily.dev/og/posts/M4qZJ1frV.png og:image:alt: Recent Developments Part III og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Recent Developments Part III **[Happenings in GNOME](https://daily.dev/sources/chergert)** · 7 min read · 0 upvotes · 0 comments ## Summary A GNOME developer describes building a full virtual test lab for hardware-wrapped storage encryption across the Linux stack, aimed at enabling GNOME OS to run reliably on phones and multi-user devices. The work spans a new Qemu UFSHCI 4.1 inline-crypto device model, dm-inlinecrypt for hardware-wrapped keys, dm-integrity layered above it, a new REQ_OP_PROVISION block-layer operation for thin-provisioning safety, ext4 support for provisioning, and cryptsetup LUKS2 tooling to tie it together. The result is a reproducible way to test encryption, integrity, suspend/resume, and provisioning without needing specialized hardware. The author notes the work is unfinished and unlikely to be pushed upstream (LKML) without community interest since they are not currently employed to do so. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is REQ_OP_PROVISION in the Linux block layer used for? REQ_OP_PROVISION is a new block-layer operation that asks the storage stack to physically back a logical range before it is published, acting as the opposite of discard. It was added to solve the problem of thin-provisioned filesystems publishing allocations before physical storage is assigned, which can otherwise cause catastrophic failures during writes to data, integrity tags, or integrity journals. It is carried through block core, loop devices, device-mapper thin volumes, dm-integrity, and ext4. _Developers hardening storage stacks can follow kernel block-layer changes like this via daily.dev._ ### How do hardware-wrapped encryption keys protect against key extraction on Linux storage devices? Hardware-wrapped keys keep the long-term AES-XTS key as an opaque, device-bound blob that never enters kernel memory in raw form; during activation it becomes a boot-scoped ephemeral blob handed to storage hardware, which derives and programs the encryption key internally. A separate 32-byte software secret handles integrity operations without revealing the inline-encryption key, reducing the value of extracting keys from a running system, though it doesn't protect plaintext already in memory. _Engineers evaluating disk encryption trade-offs can track storage security techniques like this on daily.dev._ ### How can I test UFS inline-crypto hardware encryption without physical hardware? A Qemu-based virtual UFSHCI 4.1 inline-crypto device model can emulate the hardware, supporting AES-256-XTS, 512- and 4096-byte data units, 32 keyslots, and both legacy and MCQ request formats. It models keyslot staging, eviction, zeroization on reset, and deterministic behavior under concurrent reprogramming, plus a test-only wrapped-key mailbox for exercising damaged or substituted key blobs, enabling full-stack testing of dm-inlinecrypt, dm-integrity, and cryptsetup without specialized storage hardware. _Kernel and storage engineers building emulated test hardware can find similar deep dives on daily.dev._ ## Similar posts on daily.dev - [DM-INLINECRYPT Expected For Linux 7.2 To Leverage Inline Encryption](https://daily.dev/posts/dm-inlinecrypt-expected-for-linux-7-2-to-leverage-inline-encryption-o7ptvhozs) · Phoronix · 0 upvotes · 0 comments - [Ingo Blechschmidt: "So. For the past few days I've…"](https://daily.dev/posts/ingo-blechschmidt-so-for-the-past-few-days-i-ve--e8gtze4cs) · Lobsters · 0 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux) [View this post on daily.dev](https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Recent Developments Part III","url":"https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv"},"datePublished":"2026-08-31T05:54:43.395Z","dateModified":"2026-08-31T05:56:43.222Z","description":"A GNOME developer describes building a full virtual test lab for hardware-wrapped storage encryption across the Linux stack, aimed at enabling GNOME OS to run...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Happenings in GNOME","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Happenings in GNOME","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/chergert"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Happenings in GNOME","item":"https://daily.dev/sources/chergert"},{"@type":"ListItem","position":3,"name":"Recent Developments Part III"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/recent-developments-part-iii-m4qzj1frv#faq","mainEntity":[{"@type":"Question","name":"What is REQ_OP_PROVISION in the Linux block layer used for?","acceptedAnswer":{"@type":"Answer","text":"REQ_OP_PROVISION is a new block-layer operation that asks the storage stack to physically back a logical range before it is published, acting as the opposite of discard. It was added to solve the problem of thin-provisioned filesystems publishing allocations before physical storage is assigned, which can otherwise cause catastrophic failures during writes to data, integrity tags, or integrity journals. It is carried through block core, loop devices, device-mapper thin volumes, dm-integrity, and ext4. Developers hardening storage stacks can follow kernel block-layer changes like this via daily.dev."}},{"@type":"Question","name":"How do hardware-wrapped encryption keys protect against key extraction on Linux storage devices?","acceptedAnswer":{"@type":"Answer","text":"Hardware-wrapped keys keep the long-term AES-XTS key as an opaque, device-bound blob that never enters kernel memory in raw form; during activation it becomes a boot-scoped ephemeral blob handed to storage hardware, which derives and programs the encryption key internally. A separate 32-byte software secret handles integrity operations without revealing the inline-encryption key, reducing the value of extracting keys from a running system, though it doesn't protect plaintext already in memory. Engineers evaluating disk encryption trade-offs can track storage security techniques like this on daily.dev."}},{"@type":"Question","name":"How can I test UFS inline-crypto hardware encryption without physical hardware?","acceptedAnswer":{"@type":"Answer","text":"A Qemu-based virtual UFSHCI 4.1 inline-crypto device model can emulate the hardware, supporting AES-256-XTS, 512- and 4096-byte data units, 32 keyslots, and both legacy and MCQ request formats. It models keyslot staging, eviction, zeroization on reset, and deterministic behavior under concurrent reprogramming, plus a test-only wrapped-key mailbox for exercising damaged or substituted key blobs, enabling full-stack testing of dm-inlinecrypt, dm-integrity, and cryptsetup without specialized storage hardware. Kernel and storage engineers building emulated test hardware can find similar deep dives on daily.dev."}}]} ```