NVMe Self-Study Bank: Security and Lockdown

NVMe · Q1–328

NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4

Q237–Q245

Security and Lockdown

Security commands transport protocol data; Lockdown prohibits selected operations. Separate protocol results, prohibition scope and persistence.

Each question is followed by its explanation. Start with the volume overview, then follow the field interpretations, comparisons or processes. Essential conditions and the normal path are visible from the start. All numerical examples are hypothetical. Status is written SCT/SC; h indicates hexadecimal.

SCT
Status Code Type

Transport, protocol and permission are distinct

NVMe success is not authentication success, and prohibiting Set does not automatically prohibit Get.

QuestionEvidenceWhere the answer resides
Was data exchanged?Security CQENVMe completion
Did authentication succeed?Protocol selectors/payloadSelected protocol
Is it prohibited?Interface/scope/listProhibition and target completion
Does it survive power loss?CSEL and LDPEScope-specific persistence
CQE
Completion Queue Entry

Worked interpretation: CSEL0 with LDPE1 persists, while CSEL1/2 do not gain that persistence from LDPE.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1

Review the terminology when needed
Controller / namespace
A controller receives commands and manages access. A namespace is a logical storage space that commands can address. An NVM subsystem contains controllers and nonvolatile storage resources.
SQ / CQ / SQE / CQE
Submission and Completion Queues carry command entries (SQEs) and completion entries (CQEs). QID identifies a queue, CID distinguishes outstanding commands in one SQ, and NSID identifies a namespace.
Register / Identify / Feature / Log
A register exposes control or state. Identify queries capabilities and attributes; features query or configure operation; log pages report specific state or records. FID, LID, CNS and CSI select features, logs, Identify structures and command sets.
index / offset / zero-based
An index selects an entry, usually starting at 0; an offset measures distance from an origin in specified units. A zero-based count encodes count−1, but not every zero-valued field is a count. A Dword is 4 bytes; a byte is 8 bits.
Scope / reset / retention
Scope names the affected objects; retention means preserving state. Controller Reset (clearing CC.EN) is one form of Controller Level Reset, or CLR. Different CLR triggers can retain different registers.

Questions in this volume

  1. Q237 · How are Security Send/Receive and protocols discovered?
  2. Q238 · How are invalid security selectors or lengths handled?
  3. Q239 · How are security transfer and protocol failures distinguished?
  4. Q240 · How can security state affect other Admin commands?
  5. Q241 · Does security state survive reset or power cycle?
  6. Q242 · How does Lockdown restrict commands or features?
  7. Q243 · What response is required for a prohibited command or feature?
  8. Q244 · How are normal and enhanced Lockdown logs interpreted?
  9. Q245 · Does Lockdown survive resets and power cycles?

Q237 How are Security Send/Receive and protocols discovered?

Follow the explanation

NVMe command support and security-protocol support are separate capability layers.

1. Select the target and information

OACS describes commands; discovery identifies supported SECP values.

Check the OACS support bit and Commands Supported and Effects.

Security Receive SECP00h discovers protocols without a prior Security Send.

2. Query sequence and interpretation

Discover first, then encode selectors/lengths and protocol-specific exchange ordering.

Successful discovery identifies protocols, not authentication success.

3. Handle missing or inconsistent evidence

Unsupported Receive SECP requires Invalid Field; unsupported Opcode is a different layer.

Command support does not promise every SECP.

First locate failure at command or protocol selection level.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q238 How are invalid security selectors or lengths handled?

Follow the explanation

Separate outer NVMe fields from inner protocol data to predict the right response.

1. Distinguish the failure conditions

Selectors, pointers and lengths matter; protocol definitions govern payload validity.

AL/TL follow Security Protocol In/Out with INC_512=0, not generic zero-based Dword counts.

Unsupported Receive/reserved Send SECP requires Invalid Field; inner authentication failure may be a protocol result rather than those CQE statuses.

CQE
Completion Queue Entry

2. Establish the cause from evidence

Establish supported commands and protocols before forming a request.

Validate outer fields/buffer before payload; NSSF is defined for specified EAh uses.

3. Outcome and follow-up checks

Valid transport returns protocol results that separately establish security success.

Preserve both outer CQE and inner result.

Check the AL/TL units, transfer length, and buffer capacity first. Once the data transfer is complete, use the security protocol response to diagnose credentials.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q239 How are security transfer and protocol failures distinguished?

Follow the explanation

Failed transport differs from a protocol rejecting successfully delivered data.

1. Distinguish the failure conditions

Analyze command transport before the multi-command protocol exchange.

Data Transfer Error concerns data movement; security outcomes may be encoded separately in protocol fields.

Unsupported fields, transfer failures, internal errors and authentication rejection have distinct premises.

2. Establish the cause from evidence

Preserve SQE, pointers, length, CQE and valid receive payload.

SQE
Submission Queue Entry

Establish valid returned data before decoding; stale buffers after transfer failure are not new results.

3. Outcome and follow-up checks

A successful CQE still requires protocol-result interpretation.

Correlate both layers and sequence to the intended exchange.

First distinguish protocol rejection from DMA failure.

DMA
Direct Memory Access, device access to memory

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q240 How can security state affect other Admin commands?

Follow the explanation

Security policy may restrict operations, but an unspecified Locked state does not prohibit every Admin command.

1. Mechanism and scope

Protocol, protected objects and explicit NVMe interactions determine scope.

Security transport, Lockdown and Namespace Write Protection are distinct mechanisms.

2. Understand it through actions and results

Identify the actual protocol/state, Lockdown log and applicable personality settings.

Identify command/scope, the denying mechanism and its specified response.

Permitted queries may continue, and removing one restriction need not remove others.

3. Avoid a misleading conclusion

Generic SC 23h applies to Lockdown, not every security denial.

Correlate each mechanism separately with observed behavior.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q241 Does security state survive reset or power cycle?

Follow the explanation

A testable answer requires a particular protocol and state.

1. Identify the trigger and affected objects

Keys, persistent policy, sessions and pending receive data have different lifetimes.

Record protocol/revision/state and reset source; the three NVMe specs define only their stated transport behavior.

2. State changes and recovery

Base permits loss of receive results after communication loss/CLR, not automatic erasure of persistent security settings.

Recover communication, query state and reauthenticate if the selected protocol requires it.

Correctness follows selected protocol retention, not universal keep/clear behavior.

3. Checks across reset or power loss

TriggerEffect on this operation or state
What survives or continues after Controller Reset?Pending Security Receive data may not survive CLR. Lock/session/key persistence is protocol-specific; lost transport results do not establish unlock or key erasure.
What survives or continues after NVM Subsystem Reset?Rediscover communication and protocol state after subsystem reset. Base supplies no universal authentication/lock retention rule for every security protocol.
What survives or continues after a power cycle?Recreated queues do not prove an unlocked security state after power cycle. Apply the selected protocol’s persistent/session rules; absent that choice these NVMe sources do not define one answer.

4. Verify retention and recovery

Without a protocol, do not invent statuses, unlock results or key handling; state the specification boundary.

Verify transport, session and persistent state separately.

First identify the exact field or protocol object meant by security state.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q242 How does Lockdown restrict commands or features?

Follow the explanation

Lockdown controls execution at selected interfaces/controllers, not encryption or namespace write protection.

1. Prepare the operation

CSEL selects subsystem, controller or a primary’s secondaries; IFC selects the receiving interface.

Check CFLS/CCFLS and the prohibitable list, which is implementation-defined.

SCP/OFI select opcode or FID, PRHBT controls prohibition, and CSS/UIDX select target controller/definition.

FID
Feature Identifier

2. Sequence and completion conditions

Discover, apply, await success, read current prohibition and test the matching interface.

Successful scope enforcement is idempotent for repeat prohibit/allow operations.

3. Handle unmet conditions

Nonprohibitable targets require the command-specific prohibition-not-supported status; unsupported nonzero CSEL requires Invalid Field.

Prohibiting one FID targets Set, not Get or necessarily the entire Set Features opcode.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q243 What response is required for a prohibited command or feature?

Follow the explanation

Verify actual enforcement after successful configuration.

1. Distinguish the failure conditions

Match controller, receiving interface, opcode/FID and applicable UUID.

A prohibited command received on the Admin SQ shall abort with SCT 0/SC 23h.

SQ
Submission Queue
SCT
Status Code Type

Configuration failures differ from target denial; preserve explicit CDP Authentication exceptions.

2. Establish the cause from evidence

Read current prohibitions and confirm the successful setting/scope.

Apply the restriction, submit an otherwise-valid target command and verify denial/no execution.

3. Outcome and follow-up checks

Test success means enforcement, not successful execution of the denied command.

With enabled persistence and the required authenticated-unfreeze support, CDP Authentication Send/Receive remains allowed despite prior prohibition.

First check target/interface and explicit exceptions.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q244 How are normal and enhanced Lockdown logs interpreted?

Follow the explanation

The log distinguishes prohibitable capability from current prohibitions.

1. Establish the source and scope

Normal lists can describe all controllers; enhanced lists can select one or aggregate entries reported by at least one.

Enhanced ELPF1 requires CCFLS; LSI.CNTLID is used only there.

2. Fields, units and worked interpretation

CNTTS chooses capability/Admin/OOB prohibition; SCP selects identifiers. Normal LNGTH counts bytes; enhanced sizes/counts govern descriptors.

Match returned selectors; in the enhanced aggregate, ACNTL1 means all and 0 some but not all.

If only controller 1 prohibits FID 12h, an aggregate entry with ACNTL0 means partial coverage, not no prohibition.

3. Conditions that change the interpretation

Unsupported enhanced format requires Invalid Field; enhanced log length is not universally 512 bytes.

Compare per-controller results and behavior to distinguish union from intersection.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Q245 Does Lockdown survive resets and power cycles?

Follow the explanation

Retention depends on CSEL and persistence settings, not one Lockdown-enabled flag.

1. Identify the trigger and affected objects

Separate subsystem prohibitions from selected-controller/group prohibitions.

Preserve original selectors and read actual personality LDPS.

2. State changes and recovery

LDPE is requested input and LDPS returned state; submission does not establish success.

Snapshot, perform the specified reset/power cycle and repeat the same query/behavior checks.

Ordinary reset retains restrictions; power-cycle behavior depends on scope and persistence, with no CSEL1/2 persistence extension.

3. Checks across reset or power loss

TriggerEffect on this operation or state
What survives or continues after Controller Reset?Ordinary CLR does not remove a successful prohibition; removal requires an allowed subsequent Lockdown or its specified power-cycle condition.
What survives or continues after NVM Subsystem Reset?Subsystem reset is not power cycle and does not automatically remove prohibitions; preserve scope-specific state and explicit personality exceptions.
What survives or continues after a power cycle?CSEL0 persists across power cycles only with LDPE1; otherwise power cycle removes it. CSEL1/2 end at power cycle regardless of LDPE.

4. Verify retention and recovery

Neither retention after subsystem reset nor loss of controller-scoped restrictions after power cycle is automatically a failure.

Scope, actual personality state and reset type jointly determine the expectation.

First distinguish the three actual reset/power actions.

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Source locations for this question

Sources: Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)

Back to questions

Source locations and existing figure guides

Base printed page = PDF page−26; the other two use identical numbers. Locations follow the supplied PDF body and retain figure numbers. Shared pages contribute only the relevant definitions, excluding Fabrics and PCIe link/packet content.

  • Base 2.4 · §3.7.1–3.7.4
    Printed pages 120–124 · PDF 146–150
  • Base 2.4 · §4.2.3
    Printed pages 145–155 · PDF 171–181 · Figure 101–105
  • Base 2.4 · §5.2.2
    Printed pages 183–190 · PDF 209–216 · Figure 150–156
  • Base 2.4 · §5.2.13.1.2
    Printed pages 218–220 · PDF 244–246 · Figure 212
  • Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
    Printed pages 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253
  • Base 2.4 · §5.2.13.1.20
    Printed pages 279–283 · PDF 305–309 · Figure 274–278
  • Base 2.4 · §5.2.14.2.1
    Printed pages 340–387 · PDF 366–413 · Figure 338–341
  • Base 2.4 · §5.2.16, 8.1.5
    Printed pages 405–408, 597–599 · PDF 431–434, 623–625 · Figure 365–367
  • Base 2.4 · §5.2.28–5.2.29
    Printed pages 454–456 · PDF 480–482 · Figure 456–462
  • Base 2.4 · §5.2.30.1.25.4–5.2.30.1.25.4.1
    Printed pages 493–494 · PDF 519–520 · Figure 518–519

When you need a field guide

Existing figure explanations have canonical locations; use these links instead of duplicating the same guide.

Original documents used
  • NVM Express Base Specification · Revision 2.4 · 2026-07-31
    NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf
  • NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
    NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf
  • NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
    NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Jia-Chang

Jia-Chang

Human

Recent posts

PCIe Chapter 37：效能推估與跨章觀察
PCIe Chapter 37: Performance Estimation and Integrated Observation
PCIe Chapter 36：交易依賴、ID-Based Ordering 與 Message
PCIe Chapter 36: Dependencies, ID-Based Ordering, and Messages

Comments

  Write a comment ...