PaperlayerView exact revision on arXiv

Source-linked AI summary

SxSSD: A Secure and Extensible Software-defined Solid State Drive

Josh Dafoe, Bo Chen

arXiv:2608.23365v1cs.CRcs.OS

TL;DR

Existing SSD designs either constrain FTL modification through fixed interfaces or move FTL functions into the untrusted OS, creating a flexibility–isolation gap. SxSSD decouples FTL policies from primitive mechanisms so trusted applications can dynamically define interfaces and policies while retaining isolated FTL execution. Its prototype supports security-critical applications without firmware modification and incurs 3.74% overhead over a baseline SSD.

  • Problem

    Fixed flash-to-OS interfaces limit workload-specific FTL customization and make security-critical storage semantics difficult to implement, while software-defined interfaces blur the trusted device boundary.

  • Method

    SxSSD separates generic FTL procedures from policies and provides a meta-interface for trusted applications to define host-visible storage semantics and install on-device policies.

  • Results

    3.74% overhead over a baseline SSD was observed across multiple real-world workloads, and SxSSD supported applications including secure ransomware data recovery without modifying FTL firmware.

  • Takeaways & Limitations

    SxSSD enables dynamically installed security-critical storage semantics while preserving the isolated FTL execution boundary under a compromised operating system.

  • Takeaways & Limitations

    Adapting SxSSD to SATA or SAS relies on vendor-specific commands, which provide limited capacity for custom commands.

Abstract

from arXiv · show

Solid-state drives (SSDs) are built on NAND flash memory and expose it to the operating system through a block-based storage interface. As NAND flash has special read/write constraints due to its hardware nature, a translation between OS-level I/Os and raw flash memory I/Os is needed. This results in a flash translation layer (FTL) that creates a ``trusted computing base'' due to its physical isolation from the OS. Building on this trusted computing base, some security designs (e.g., data recovery from malware attacks) can ensure strong data security properties even if the OS is compromised. However, they mostly require modifying the FTL's firmware code, which is hard in practice because the traditional block-based FTL does not provide an interface to modify its internal functions. New flash storage interface designs, such as open-channel SSDs or zoned namespaces, have moved key FTL functions into the OS. These interfaces ease modification of FTL functions, at the cost of blurring the trusted boundary, as the FTL is no longer isolated from the OS. In this work, we have introduced SxSSD, a secure yet extensible software-defined SSD design. By decoupling internal policy definitions from primitive FTL mechanisms, we allow trusted applications to dynamically and securely define FTL policies and the exposed storage interface (achieving increased flexibility compared to open-channel and zoned namespaces SSDs). Most significantly, SxSSD retains the isolation of traditional FTL execution (achieving security similar to traditional block-based SSDs). We have identified and addressed key security challenges introduced under a compromised OS. In addition, we have implemented a prototype of SxSSD and evaluated its overhead with different FTL policies and storage interfaces. Experimental evaluation demonstrates that the overhead incurred by SxSSD is small compared to native FTL implementations.

1 Introduction

SxSSD addresses the fixed flash-to-OS interface in existing SSD designs, which limits workload-specific performance and security-critical storage semantics. It makes storage interfaces and FTL policies dynamically definable while preserving isolated FTL execution, and prototype results show small overhead.

  • Motivation: NAND flash’s erase and access constraints require an FTL to translate OS requests into flash operations.Data is erased in block-sized units, while reads and writes use page-sized units; updates therefore cannot overwrite pages in place.
  • Problem: Existing SSD designs expose fixed flash-to-OS interfaces, limiting coordination between workloads and device-level FTL behavior.This constrains high-performance storage customization and makes modifying FTL-based security semantics difficult.
  • SxSSD: SxSSD dynamically defines the flash-to-OS interface and supporting FTL policies on top of generic FTL procedures while maintaining the trusted device boundary.Trusted applications can install custom policy code and storage semantics without modifying FTL firmware.
  • Security: SxSSD secures policy extensibility through authorized policy management, attestation, freshness, integrity, and confidentiality mechanisms.The design restricts policy management to trusted entities even when the host OS is untrusted.
  • Evaluation: 3.74% overhead over a baseline SSD was measured across multiple real-world workloads in the SxSSD prototype.The prototype was implemented in an SSD emulator and evaluated with multiple workloads; a case study also enabled secure ransomware data recovery without modifying FTL firmware.

2 Background

NAND flash imposes page-, block-, sequential-write, and endurance constraints, so FTLs translate higher-level I/O into compliant operations. Existing interfaces expose different balances of abstraction and host control, while their functionality can be layered across designs.

  • NAND Flash Characteristics: NAND flash writes pages, erases blocks before overwrites, often requires sequential writes, and has limited block endurance.These constraints make direct presentation of raw flash difficult and require translation software.
  • Flash Translation Layers: FTLs translate host I/O into raw flash operations while providing a logical interface over NAND-specific semantics.The FTL runs on the storage controller and preserves expected storage semantics despite complex operation dependencies.
  • Open-Channel SSDs: OCSSDs expose flash structure and parallelism, allowing the host to control placement through fixed logical mappings and sequential write pointers.Chunks group logical blocks around parallel units, while chunk state, erase, and wear information support flash constraints.
  • Zoned Namespaces SSDs: ZNS exposes logical zones with sequential-write constraints while managing physical placement internally through zone write pointers, state, erase, and wear leveling.Zones can span aligned blocks across multiple dies or an entire superblock.
  • Block-interface SSDs: Block-interface FTLs hide flash constraints behind random logical reads and writes, out-of-place updates, mapping tables, striping, wear leveling, and bad-block management.New writes are commonly striped across superblocks to maximize internal parallelism.
  • Unifying FTL Designs: Block abstractions can be implemented over ZNS or OCSSD, and ZNS can be built over OCSSD, suggesting shared internal FTL machinery across interfaces.This observation motivates a unified characterization of the FTL design space.

3 Models and Assumptions

The model assumes correctly running SxSSD firmware and trusted applications, while treating the host OS and its communication channel as adversarial. Device and administrator credentials support authenticated trust relationships.

  • System Assumptions: The SSD is assumed to run correct SxSSD firmware, protected by hardware isolation and potentially secure boot against unauthorized modification.DRAM-cache data loss from power failure is not considered.
  • Trusted Applications: Trusted applications are assumed to be controlled by a trusted administrator and protected from a compromised OS using secure execution or boot mechanisms.Examples include trusted execution environments, secure bootloaders, and remote trusted computers.
  • Adversary Model: The host OS is modeled as compromised and able to control SSD communication, while remaining unable to feasibly break cryptographic primitives.The adversary may obtain root access and invoke the SSD interface at any time.
  • Key Provisioning: The SSD contains a manufacturer-embedded device key pair, while the administrator obtains a certified key pair provisioned through secure communication.Certificates bind the device and administrator keys for authenticated interaction.

4 A Characterization of the FTL Design Space

The FTL design space is characterized by sequential write domains, associated state machines, and event-triggered policies. SxSSD separates fixed mechanisms from programmable policy layers so trusted applications can define exposed storage semantics.

  • Shared FTL Structure: FTLs stripe writes across hardware hierarchy levels and differ in striping-domain size, striping level, and host exposure.Block-interface, open-channel, and ZNS designs all manage internal striping through sequential-write constraints.
  • Internal Parallelism and Sequential Write Domains: A sequential write domain is the logical view of a striping domain, advancing a logical write pointer while placing writes across underlying physical pages.A ZNS zone is an example of an SWD whose striping domain can be a superblock.
  • SWD State: SWDs use state machines tracking mapping, wear, write pointers, and state, with policy-defined state optionally becoming host-visible.The remaining state stays internal to the device.
  • Event-driven Policies: Policy actions are event driven: state changes from writes, erases, commands, transitions, background processing, and primitive-operation errors trigger policy behavior.Conditions over per-SWD state determine when actions execute.
  • Conceptual Model: The conceptual FTL model separates raw flash, BBM and SWD mechanisms, events, policy-defined eSWD state, and event-attached condition-action policies.These five components unify common FTL organization while isolating programmable policy semantics.
  • SxSSD Extensibility: SxSSD fixes raw flash, BBM, and event mechanisms while making eSWD organization and policies programmable through a meta-interface.Policies define eSWD size, striping level, context, state machines, and host-visible semantics through condition-action functions.

5.1 Design Overview

SxSSD implements programmability through a flash subsystem, policy engine, and secure meta-interface. Policies are stored, loaded, and dispatched on device events, while the meta-interface manages their lifecycle under access restrictions.

  • Architecture: SxSSD’s FTL structure has three components: a flash subsystem API, an event-routing policy engine, and a meta-interface for secure policy management.The flash subsystem instantiates mechanism layers, the policy engine executes policy code, and the meta-interface manages policy definitions.
  • Secure Policy Management: The meta-interface supports installing, updating, deactivating, and removing policies, but must restrict access because exposing it to an untrusted OS creates an attack surface.Only trusted applications should manage policies against an actively adversarial host OS.
  • Policy Engine: The policy engine stores and loads policies, maintains runtime state, and dispatches event-specific condition-action handlers.Events include NVMe commands, primitive-SWD transitions, flash-operation errors, and background processing.
  • Flash Subsystem: The flash subsystem builds from primitive page and block operations with BBM and higher-level abstractions exposed through a defined policy interface.This interface enables policy functions to interact with flash storage while respecting underlying NAND mechanisms.

5.2 The Meta-Interface

The meta-interface lets trusted applications manage SxSSD policies through authenticated vendor-specific NVMe commands, even when the host OS is untrusted. It protects policy requests against forgery, replay, disclosure, and inconsistent policy state.

  • Authorized Policy Management with Replay Protection: Vendor-specific NVMe commands provide the meta-interface for securely managing on-device policies.Each command triggers a policy-engine event; requests are restricted to trusted entities through authentication.
  • Authorized Policy Management with Replay Protection: INIT_SESSION establishes a trusted-application session and generates a shared key Ks through authenticated key exchange.Subsequent policy-management requests use this session key.
  • Authorized Policy Management with Replay Protection: MAC authentication covers both the NVMe opcode and request data, allowing the FTL to verify request source and integrity.Authenticating the opcode prevents an attacker from altering which command the SSD processes.
  • Authorized Policy Management with Replay Protection: Session keys and counters prevent replayed policy-management requests, including attempts to downgrade active policies.Counters reset with a successful INIT_SESSION and are included in request authentication.
  • Policy Confidentiality: Confidential mode encrypts policy request data, while policy code is stored in inaccessible over-provisioned space outside host-visible mappings.This prevents an adversarial OS from learning policy semantics or directly accessing policy storage.
  • Policy Attestation: POLICY_ATTESTATION reports whether a policy is installed and active, or additionally reports a policy-code hash for consistency checking.Attestation makes discrepancies between expected and actual policy state detectable.

5.3 Policy Engine

The policy engine loads active policies at startup and dispatches runtime events to their condition and action functions. These functions interact with storage through the FTL API.

  • Policy Engine: At startup, the policy engine identifies active policies from metadata and loads their code into RAM.Active policies are stored in flash before initialization but are not initially resident in system RAM.
  • Policy Engine: For each runtime event, DISPATCH selects the associated table and executes active entries’ condition functions before their action functions.Policy functions can call the FTL API to interact with the storage system.

5.4 Flash Subsystem

The flash subsystem separates raw device constraints, bad-block management, and policy-facing abstractions. Its FTL API exposes configurable eSWDs and primitives for implementing varied storage policies.

  • Flash Subsystem: The flash subsystem has three layers: raw flash operations, bad-block management, and the policy-facing FTL API.The layers correspond to device-enforced constraints and policy-enforced mechanisms.
  • Flash Subsystem: Raw flash operations enforce constraints C1-C4 over physical blocks and pages and report errors as policy-engine events.Policies can respond to these events by invoking bad-block-management functions.
  • Bad-Block Management: Bad-block management creates pseudo-physical block addresses, maps them to physical blocks, and maintains primitive sequential-write-domain state.Each pseudo-physical block is a block-sized striping domain with page-level striping.
  • FTL API: The FTL API introduces eSWDs that group pSWDs and translate policy-visible reads, sequential writes, and erases into BBM operations.Each eSWD maintains size, striping level, write pointer, and mappings onto pSWDs.
  • FTL API: SET_ESWD_SIZE and SET_STRIPING_LEVEL let policies configure the number and layout of eSWDs during INIT_POLICY.Exactly one policy should invoke these configuration functions.
  • FTL API: The FTL API also supports mapping management, wear-leveling, higher-level random-write mappings, and garbage collection.These features are provided through eSWD migration and additional mapping-table primitives.

6 Analysis and Discussion

SxSSD secures extensible policy management while preserving the trusted device boundary, but its guarantees depend on trusted policy administrators and constrained policy code. The design can also be adapted to SATA and SAS with command-capacity limits.

  • Security Analysis: The meta-interface authenticates requests, prevents replay, supports confidential sessions, and isolates policy storage from policy-visible mappings.These mechanisms address security requirements under an untrusted host OS.
  • Security Analysis: SxSSD cannot prevent denial-of-service attacks under the stated adversary model, but attestation makes inconsistencies between expected and actual states detectable.The availability requirement is therefore framed around effective administrator detectability rather than DoS prevention.
  • Discussion: Policy-code safety assumes a trusted administrator; code outside the FTL API or containing memory-safety bugs may corrupt policy storage or reveal policy semantics.Static analysis and runtime capability restriction are identified as future mitigations.
  • Discussion: POLICY_ATTESTATION may be insufficient when authorized policy managers mutually distrust one another because it audits only current state, not policy transitions over time.Authenticated evidence of policy transitions is left for future work.
  • Adapting SxSSD to Other SSD Interfaces: SxSSD can be ported to SATA and SAS using vendor-specific commands, but policies have limited command space: SATA supports 27 and SAS supports 64 commands.The policy engine and flash subsystem need not change significantly for this port.

7 Implementation and Evaluation

SxSSD is implemented and evaluated through policy-management, semantic-equivalence, performance, and security-policy experiments. Across workloads, its baseline policy closely matches native FTL behavior while adding small overhead, and FlashGuard requires limited policy code.

  • SxSSD is evaluated through policy-management efficiency, native-FTL overhead, and support for security-critical storage semantics.The study uses real-world workloads and throughput benchmarks to assess these questions.
  • SxSSD is implemented on FEMU, including a 543-line SxSSD-Block policy matching FEMU’s native block-interface semantics and an SxSSD-FlashGuard case study.
  • Meta-interface Performance: Consistency-mode policy attestation takes 41% longer than security-mode attestation, while both remain trivially fast.Consistency mode hashes the entire policy code; security mode validates two bits of information.
  • Semantic Equivalence: Baseline and SxSSD-Block invoke garbage collection and erase blocks identically across workloads, while physical page write counts differ by at most 0.042%.For workloads with more than 100,000 migrated pages, average migration-count difference is 0.52%.
  • Baseline Overhead: 3.74% average write-latency overhead accompanies a 0.069% random-read IOPS decrease and a 4.617% random-write IOPS decrease versus baseline.The evaluation characterizes read overhead as negligible and write overhead as small.
  • Recovery From Ransomware Attacks: 533 additional lines of policy code implement SxSSD-FlashGuard without changing the FTL, and mean write latency rises by 0.86% on average versus SxSSD-Block.The maximum increase is 4.50% for the S6 workload.

8 Related Work

Related work spans software-defined SSD interfaces, extensible SSDs, FTL-based security semantics, and generic FTL frameworks. SxSSD differs by targeting programmable NAND-flash FTL behavior while preserving device-side security isolation.

  • Software-Defined and Extensible SSDs: Software-defined SSDs such as OCSSDs and ZNS move FTL functions toward the host OS and expose interfaces closer to flash operations.
  • Software-Defined and Extensible SSDs: Willow supports device-enforced application-defined semantics but uses simulated phase-change memory and does not make a NAND-flash FTL programmable.Willow also does not consider a compromised OS.
  • FTL Based Security Critical Storage Semantics: Prior FTL-security systems support semantics including ransomware recovery, plausible deniability, and self-protection by extending the FTL.
  • Generic FTL Frameworks: HIL and OX provide generic frameworks for constructing flexible or custom FTLs through layered mappings, logs, modular components, and defined interactions.

9 Conclusion

SxSSD provides trusted applications with dynamically installable FTL policies and changeable storage interfaces while retaining isolated device-side FTL execution. Its prototype demonstrates security-critical storage semantics and evaluates performance across real-world workloads.

  • SxSSD enables trusted applications to program FTL behavior through custom policies while retaining the isolated FTL as a security boundary.
  • SxSSD supports dynamically installed security-critical storage semantics under a compromised operating system, demonstrated through secure ransomware-data recovery.
  • The implemented prototype is evaluated across several real-world workloads.
Loading 2608.23365v1…