Security Services Changes#

HPSE Drivers - NVVSE Changes#

NVVSE IVC Configuration Device Tree Format Change#

Target Changes

Backward Compatible

Platform

OS

With 7.2.6.0, in support of the NVVSE pluggable engine abstraction architecture, the NVVSE IVC channel configuration in the device tree moves from a single packed integer array to a phandle-referenced, per-node format on both Linux and QNX.

Previously, the ivccfg property held a flat, position-dependent array of integer tuples, one fixed-width tuple per channel, accessed by index. Now each VSE IVC channel is defined as its own child node under nvvse-ivccfgdb with named properties, and the configuration references those nodes by phandle:

  • On QNX, the nvvseivccfg node (compatible = "nvvseivccfg,channel-db") lists the channels through ivccfg = <&nvvse_ivccfg_300_alias>, ... and declares the count in num_ivc_entry.

  • On Linux, per-engine nodes (vse@xxxx / vtsec@xxxx) use compatible = "nvvse-plug-arch" and reference their channels through nvidia,ivccfg with the count in nvidia,ivccfg_cnt.

Each child node exposes named properties, for example, se_comm_id, se_domain, se_port, se_domain_instance_id, virtual_instance_id, priority, max_buffer_size, channel_group_id, and se_sid, in place of the former fixed tuple positions. A zero_copy_supported property is also present per channel: when set to 1 zero-copy is enabled for that channel, and when set to 0 zero-copy is disabled.

The NVVSE open path, QNX device-node naming, thread-priority DT naming, IVC discovery, and QNX custom ability range were also aligned with the se_comm_id based channel model.

TSEC-specific CMAC batch APIs were renamed to generic AES CMAC batch APIs.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Release Paths

7.0 to 7.2, 6.x to 7.x

Migration Rationale

Changed in support of the NVVSE pluggable engine abstraction architecture. The former index-based tuple layout was position-dependent and could not be extended without changing the fixed tuple width. Named per-node properties referenced by phandle make the configuration self-describing and let per-channel attributes evolve independently per SoC (Orin and Thor).

Steps to Migrate

Any device-tree source that configures NVVSE IVC channels using the old packed ivccfg integer array must be regenerated in the per-node format:

  1. Define one child node per IVC channel under nvvse-ivccfgdb, each with a phandle label, for example, nvvse_ivccfg_300_alias, and the named channel properties. See DT Configuration for VSE Driver in the NVIDIA DriveOS SDK Developer Guide for the full property list and the Orin/Thor value ranges.

  2. QNX: in the nvvseivccfg node, replace the packed ivccfg array with a phandle list and set num_ivc_entry to the number of phandles. The supported range is 1 to 75.

    nvvseivccfg {
    compatible = "nvvseivccfg,channel-db";
    num_ivc_entry = <3>;
    max_aes_gcm_enc_size = <16777200>;
    ivccfg = <&nvvse_ivccfg_300_alias>,
             <&nvvse_ivccfg_301_alias>,
             <&nvvse_ivccfg_302_alias>;
};

  3. Linux: in each engine node, set compatible = "nvvse-plug-arch" and reference the channels through nvidia,ivccfg with the count in nvidia,ivccfg_cnt.

    vse@xxxx {
    compatible = "nvvse-plug-arch";
    se_port = <1>;
    se_engine_domain = <0>;
    se_engine_domain_instanceId = <0>;
    iommus = <&smmu... ...>;
    nvidia,ivccfg_cnt = <1>;
    nvidia,ivccfg = <&nvvse_ivccfg_301_alias>;
    status = "okay";
};

  4. Keep the DT configuration aligned with the PCT. Buffer sizes, SMMU SID values (se_sid versus the engine iommus SID), enabled channels, stream IDs, virtual instance IDs, zero-copy support, and engine selection must match the platform configuration.

  5. If the platform carries custom QNX NVVSE thread-priority DT entries for channels enumerated as /dev/nvvse/<se_comm_id>, update the per-channel entry under thread-priority/nvvse-safety so that both the node name and thr-name match the corresponding se_comm_id. Earlier entries used engine-derived names such as sha0, aes00, tzsha0, and tsecaes0. Newer se_comm_id based entries use numeric names such as 300, 301, and 347.

    The node is a direct child of nvvse-safety and uses the QNX thread-priority properties such as thr-prio, thr-prio-range, thr-priv, and thr-runmask. The fixed service thread names remain main, vse_pulse_handler, and nvdvms_events_listener.

    / {
    thread-priority {
        nvvse-safety {
            300 {
                thr-name="300";
                thr-prio=<0xC>;
                thr-prio-range=<&qm_prio_range_other>;
                thr-priv=<0x0>;
                thr-runmask=<0xFFFFFFFF>;
            };
        };
    };
};

  6. For T23x and T264, keep the internal and customer DT ownership split. Camera zero-copy entries are present in the internal DT because they are intended for the camera use case. The remaining NVVSE DT entries are present in customer DTs. Clients adding or modifying non-zero-copy NVVSE channels should update the customer NVVSE channel database and customer ivccfg list. Camera zero-copy entries should remain in the internal DT unless the change is coordinated internally.

Example DT Migration

The old QNX ivccfg entry encoded all channel attributes in one position-dependent tuple:

ivccfg = <300 0x2 0x0 0x0 2097152 2283
          &smmu_niso1 TEGRA_SID_NISO1_SE_VM0
          0 0x0 0 0x0 0xFF>;

In the new format, the ivccfg list contains only a phandle reference:

ivccfg = <&nvvse_ivccfg_300_alias>;

The channel attributes move into a separate named node under nvvse-ivccfgdb:

nvvse-ivccfgdb {
    nvvse_ivccfg_300_alias: nvvse_ivccfg_300 {
        se_comm_id = <300>;
        label = "Default_GPSE_SHA";
        se_domain = <NVVSE_SE_DOMAIN_NON_SECURE>;
        se_port = <NVVSE_SE_PORT_SHA>;
        se_domain_instance_id = <0>;
        virtual_instance_id = <0>;
        priority = <0>;
        max_buffer_size = <2097152>;
        zero_copy_supported = <0>;
        channel_group_id = <2283>;
        se_sid = <&smmu_niso1 TEGRA_SID_NISO1_SE_VM0>;
        gcm_decrypt_supported = <0>;
        gcmdec_max_buffer_size = <0>;
        gcmdec_mempool_id = <0>;
        gcmdec_mempool_size = <0>;
        thread_attr = <0xFF>;
    };
};

The main changes are:

Old tuple field

New property

IVCNumber

se_comm_id

SE Engine ID

Split into se_domain, se_port, and se_domain_instance_id

ID

virtual_instance_id

Priority

priority

Map_Buf_size

max_buffer_size

GID

channel_group_id

SID

se_sid

GCM_Decrypt_Supported_Flag

gcm_decrypt_supported

GCM_Decrypt_Buffer

gcmdec_max_buffer_size

Mempool ID

gcmdec_mempool_id

Mempool size

gcmdec_mempool_size

Flag_to_skip_thrd_prio_CPU_aff

thread_attr

No old tuple field

label

The label property is a new field in the structured DT format. It did not exist in the old packed tuple. The label provides a human-readable channel purpose, for example, Default_GPSE_SHA, NV_Camera_DMS_SHA_0, NV_Camera_OMS_HMAC_0, MACSEC_1, or DTLS_RX_low_lat_TX_1. The label is also returned through the public NvVseGetIVCDB() API, so camera and other client applications can use it to identify the intended channel instead of depending only on numeric se_comm_id values.

The zero_copy_supported property is also explicit in the new format. zero_copy_supported = <1> enables zero-copy for that channel, and zero_copy_supported = <0> disables it.

IVC Channel Discovery

The NVVSE IVC channel database can now be discovered through the public NvVseGetIVCDB() API. The returned entries expose channel attributes such as se_comm_id, label, domain, port, virtual instance, priority, mapped buffer size, channel group ID, stream ID, GCM decrypt support, and zero-copy support.

Clients that previously depended on hardcoded IVC channel assumptions should use NvVseGetIVCDB() to discover available channels. Clients using the default platform configuration do not need a source change only because this API is now public.

TSEC CMAC Batch API Rename

TSEC-specific CMAC batch APIs were renamed to generic AES CMAC APIs. The legacy names remain available as inline compatibility wrappers in the public header, but new client code should use the generic names and rebuild against the updated header.

Old API or Type

New API or Type

NvVseTsecCMACBatchSignVerify()

NvVseAesCMACBatchSignVerify()

NvVseTsecCMACBatchSignVerifyParams

NvVseAesCMACBatchSignVerifyParams

NvVseTsecCMACUnitParam

NvVseAesCMACUnitParam

NvVseOpen()

NvVseOpen() changed from an engine-type based open model to a se_comm_id based open model.

Earlier prototype:

typedef struct {
    uint32_t instance;
    NvVseEngineType eEngineType;
} NvVseEngineInfo;

NvVseStatus NvVseOpen(NvVseHandle *pHandle,
                      NvVseEngineInfo *pVSEinfo);

New prototype:

NvVseStatus NvVseOpen(NvVseHandle *pHandle,
                      uint32_t se_comm_id);

In the earlier model, clients selected an NVVSE engine by passing NvVseEngineInfo, which contained an NvVseEngineType such as NVVSE_AES0, NVVSE_AES1, NVVSE_SHA, NVVSE_TZAES0, NVVSE_TZAES1, NVVSE_TZSHA, or NVVSE_TSECAES, plus an instance value. The library used the engine type to derive engine-named resource-manager device nodes such as /dev/nvvse/aes0, /dev/nvvse/aes1, and /dev/nvvse/sha.

In the new model, the driver enumerates NVVSE device nodes by se_comm_id instead of fixed engine names. Device nodes now use the /dev/nvvse/<se_comm_id> format, for example, /dev/nvvse/300 and /dev/nvvse/301. The caller passes the same se_comm_id to NvVseOpen().

NvVseOpen() uses se_comm_id to find the matching entry in the NVVSE IVC database, derive the associated channel attributes such as port, mapped buffer size, and virtual instance, and open the matching /dev/nvvse/<se_comm_id> device node.

This aligns NvVseOpen() with the pluggable engine abstraction, where channel selection is driven by the IVC channel database instead of a fixed engine-type enum. These changes are internal to DRIVE OS and aligned with DRIVE OS internal users. There is no external customer impact due to this change, and no external customer migration action is required for NvVseOpen().

Custom Ability Range

The QNX custom ability range for nvvse/Engines changed with the move from engine-type based access control to port-based access control.

Earlier releases used one ability ID per engine type:

nvvse/Engines:0-6

where the range covered GP AES0, GP AES1, GP SHA, TZ AES0, TZ AES1, TZ SHA, and TSEC AES.

Newer releases use port-based access IDs:

nvvse/Engines:0-1

where 0 grants access to AES-port NVVSE operations and 1 grants access to SHA-port NVVSE operations. Clients that explicitly configure QNX abilities for NVVSE should update launch and security-policy entries from the legacy engine range to the new port range. For example:

-A nonroot,allow,able=nvvse/Engines:0-1

API Changes for Encryption and Decryption#

Target Changes

Backward Compatible

Platform

OS

Pre 7.0.3.0:

Encryption: No parameter is required for CKM_AES_CTR. Implicit counter width is 32. Use C_NVIDIA_EncryptGetIV to retrieve the IV.

Decryption and encryption with CKA_NVIDIA_CALLER_NONCE: Requires CK_AES_CTR_PARAMS with ulCounterBits set to 32

Post 7.0.3.0:

Encryption (with and without CKA_NVIDIA_CALLER_NONCE) and Decryption: CK_AES_CTR_PARAMS parameters are required for CKM_AES_CTR. Supports variable counter width (such as ulCounterBits) from 1 to 32

Yes, If no parameter is supplied for CKM_AES_CTR encryption, the implicit value of 32 is used for the counter width

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Rationale

The change improves the CKM_AES_CTR mechanism implementation to allow for variable counter widths.

Steps to Migrate

Encryption (with and without CKA_NVIDIA_CALLER_NONCE) and Decryption: CK_AES_CTR_PARAMS parameter is required for CKM_AES_CTR. Supports variable counter width (such as ulCounterBits) from 1 to 32. If no parameter is supplied for CKM_AES_CTR encryption, the implicit value of 32 is used for the counter width

API Changes for PKCS#11 Library Known Answer Test#

Target Changes

Backward Compatible

Platform

OS

With 7.2.3.0, in the event of a failure in the PKCS#11 Library Known Answer Test, DriveOS shall not transition to the INIT_DONE state

Yes

NSR, SR

QNX

Migration Path

  • Orin to Thor

Migration Rationale

If initialization fails, the system must not transition to INIT_DONE. Added the requirement to explicitly state that “DriveOS shall not transition to INIT_DONE state on any failure in Known Answer Test (KAT)

Steps to Migrate

Not applicable

API Changes for PKCS#11 Library C_GenerateRandom#

Target Changes

Backward Compatible

Platform

OS

With 7.0.3, any function call to PKCS#11 Library C_GenerateRandom with 0 data length is classed as a valid call returning CKR_OK, whereas it used to return CKR_ARGUMENTS_BAD

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

C_GenerateRandom function returned CKR_ARGUMENTS_BAD for 0 length data, but according to specification it is allowed. The change is to return CKR_OK, but not modify data

Steps to Migrate

For C_GenerateRandom, if 0 data length is used for error checks, check for 0 data directly instead of calling C_GenerateRandom

API Changes for PKCS#11 Library C_GetMechanismInfo,#

Target Changes

Backward Compatible

Platform

OS

With 7.0.3, PKCS#11 Library C_GetMechanismInfo, RSA key size is now returned with modulus size in bits rather than a fixed value of 4 bytes

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

C_GetMechanismInfo, function returned the allowed exponent size for RSA keys, but since this is a fixed value for most keys it is of no use to users. Instead, RSA keys are more commonly measured by the modulus size, 2K, 3K, 4K keys

Steps to Migrate

If allowed RSA keys are checked with C_GetMechanismInfo, either update to check modulus size or if exponent size is required, use NVPKCS11_MAX_KEY_EXPONENT and NVPKCS11_MIN_KEY_EXPONENT defines from nvpkcs11_public_defs.h

API Changes for PKCS#11 Library C_SignInit#

Target Changes

Backward Compatible

Platform

OS

With 7.0.3, PKCS#11 Library C_SignInit, the return value for Private keys is updated from CKR_DEVICE_ERROR to CKR_OPERATION_ACTIVE when all key slots are currently in use

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Rationale

Changed for consistency in error handling. RSA and EC public keys return CKR_OPERATION_ACTIVE if keyslot is in use, whereas EC Private keys returned CKR_DEVICE_ERROR

Steps to Migrate

Update accordingly if relying on this error to trigger a retry of the call to C_SignInit

API Changes for PKCS#11 Library C_GetSlotInfo,#

Target Changes

Backward Compatible

Platform

OS

With 7.2.4.0, PKCS#11 Library C_GetSlotInfo, the fields slotDescription and manufacturerID returned within CK_SLOT_INFO structure shall reflect values programmed into Device Tree.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Release Paths

7.0 to 7.2 6.x to 7.x

Migration Rationale

Changed in support of pluggable architecture. Prior to 7.2.4.0, slotDescription has the value Orin, irrespective of Orin or Thor SOC; manufacturerID is NVIDIA

Steps to Migrate

Update accordingly if relying on the content of these fields for any display or filtering purposes.

API Changes for Linux NVVSE Driver Functionality#

Target Changes

Backward Compatible

Platform

OS

With 7.2.3.0, Linux NVVSE driver functionality can no longer be invoked via Linux kernel Cryptography API.

No

NSR, SR

Linux

Migration Path

  • Thor to Thor

  • Dimensity C-X1 to Dimensity C-X1

Migration Release Paths

7.0 to 7.2, 6.x to 7.x, 7.2.2.0 to 7.2.3

Migration Rationale

Invoking Linux NVVSE driver functionality through the Linux crypto API was unofficially supported but redundant and required custom context to be passed in addition to the crypto context structure which should ideally be hidden in driver.

Steps to Migrate

Use PKCS#11 interface documented in the NVIDIA DriveOS SDK Developer Guide.

API Changes for Non-Sensitive Key Usage#

Target Changes

Backward Compatible

Platform

OS

With 7.2.4.0, using a non-sensitive key for cryptographic operations (encryption or signature) via the PKCS#11 Library results in CKR_KEY_FUNCTION_NOT_PERMITTED.

No

NSR, SR

Linux and QNX

Migration Path

  • Thor to Thor

  • Orin to Thor

Migration Release Paths

7.0 to 7.2, 6.x to 7.x, 7.2.3.0 to 7.2.4

Migration Rationale

Changed in support of error accuracy. Prior to 7.2.4.0 using a non-sensitive key for cryptographic operations (encryption or signature) via the PKCS#11 Library results in CKR_DEVICE_ERROR.

Steps to Migrate

Update accordingly if relying on the error return to decide further action.

API Changes using CTR Mode via the PKCS#11 Library#

Target Changes

Backward Compatible

Platform

OS

With 7.2.4.0, using CTR mode via the PKCS#11 Library returns CKR_DATA_LEN_RANGE or CKR_ENCRYPTED_DATA_LEN_RANGE when block count exceeds the amount allowed by the counter width.

No

NSR

SR

Linux and QNX

Migration Path

  • Thor to Thor

  • Orin to Thor

Migration Release Paths

7.0 to 7.2, 6.x to 7.x, 7.2.3.0 to 7.2.4

Migration Rationale

Changed in support of error accuracy. Prior to 7.2.4.0, the maximum number of blocks was enforced only for encryption and returned CKR_ARGUMENTS_BAD.

Steps to Migrate

Update accordingly if relying on the error returns to decide further action.

API Changes for Decryption with CKM_AES_CBC_PAD#

Target Changes

Backward Compatible

Platform

OS

With release 7.2.5.0, the output buffer sizing behavior of all PKCS#11 decryption APIs changes when used with CKM_AES_CBC_PAD.

Prior to 7.2.5.0, a buffer-size query (NULL output pointer) returns the actual plaintext length after padding removal. From 7.2.5.0, it returns the ciphertext length (worst-case plaintext length). The actual plaintext length is only revealed once decryption is complete and the data is in the caller’s buffer.

Providing a buffer smaller than the ciphertext length now consistently returns CKR_BUFFER_TOO_SMALL. Buffers sized to the expected plaintext length or to ciphertextLen - 16 are no longer accepted.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

  • Thor to Thor

Migration Release Paths

6.x to 7.x, 7.2.4.0 to 7.2.5.0

Migration Rationale

The new behavior withholds the plaintext length until decryption is complete. This change is intentional and cannot be worked around.

Steps to Migrate

Always provide an output buffer sized to at least the ciphertext length when calling a decryption API with CKM_AES_CBC_PAD. Do not size the buffer to the expected plaintext length or to ciphertextLen - 16.

The two-step allocation pattern continues to work correctly. The buffer-size query now returns the ciphertext length rather than the plaintext length; allocate accordingly and the decryption call will update the length to the actual plaintext size on return.

Callers that infer plaintext size by other means and supply an undersized buffer will now consistently receive CKR_BUFFER_TOO_SMALL.

API Changes for AES CMAC Batch Operations on Thor#

Target Changes

Backward Compatible

Platform

OS

On Thor, CKM_AES_CMAC batch sign and verify operations (CKF_NVIDIA_BATCH_MESSAGE_SIGN / CKF_NVIDIA_BATCH_MESSAGE_VERIFY) require a channel with an IVC size of 8 KB or less. The default 1 MB channel is not supported. Applications migrating this use from Orin to Thor using the default channel will receive an error return.

No

NSR, SR

Linux and QNX

Migration Path

  • Orin to Thor

Migration Release Paths

6.x to 7.2.4.0

Migration Rationale

The 8 KB IVC size constraint for CMAC batching on Thor is an architectural limitation of the platform. The non-default channel initialization path is fully supported and sufficient for all affected use cases.

Steps to Migrate

Identify a channel with an IVC size of 8 KB or less using one of the following approaches, then initialize it with C_NVIDIA_InitializeChannel and establish a session using C_NVIDIA_OpenSession before performing CMAC batch operations.

  1. Use C_NVIDIA_GetChannelIdList and C_NVIDIA_GetChannelIdAttributeValue to enumerate available channels and select one whose CKA_NVIDIA_MAPPED_BUFFER_SIZE is 8 KB (8192 bytes) or less.

  2. Refer to the VSE clients configuration table to identify a channel with a suitable IVC size and use its ID directly.

NV_CK_FUNCTION_LIST Dispatch Table Layout Change#

Target Changes

Backward Compatible

Platform

OS

Two new function-pointer fields, C_NVIDIA_GetChannelIdList and C_NVIDIA_GetChannelIdAttributeValue, were inserted into NV_CK_FUNCTION_LIST after C_NVIDIA_BatchMessageVerifyFinal and before C_NVIDIA_BatchDigestInit. The struct’s overall size grew by two pointers, and the offsets of C_NVIDIA_BatchDigestInit and C_NVIDIA_BatchDigest within the struct shifted. Symbolic field access is unaffected.

No (ABI). Source compiled against the new header is unaffected when fields are accessed by name; however the struct grew by two pointers and the offsets of C_NVIDIA_BatchDigestInit / C_NVIDIA_BatchDigest shifted, so binaries compiled against the old header dispatch to the wrong function pointer at runtime.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

The dispatch table must expose the new GetChannelIdList / GetChannelIdAttributeValue entry points so clients reaching the API via NV_CK_FUNCTION_LIST can call them.

Steps to Migrate

  1. Code that allocates or memcpy’s NV_CK_FUNCTION_LIST against a fixed size, persists it or relies on hardcoded offsets of the BatchDigest entries within the struct must be rebuilt against the new header. Symbolic field access continues to work unchanged:

    // Offset/size-based access — breaks when fields shift.
NV_CK_FUNCTION_LIST *list = ...;
void **slots = (void **)list;
slots[11](session, mech);   // assumed BatchDigestInit at slot 11
memcpy(out, list, OLD_NV_CK_FUNCTION_LIST_SIZE);  // hardcoded size

    // Symbolic access — recompile against the new header, no source change needed.
NV_CK_FUNCTION_LIST *list = ...;
list->C_NVIDIA_BatchDigestInit(session, mech);
memcpy(out, list, sizeof(*list));   // size from the struct itself

Public-Macro Renames and Deprecated Aliases#

Target Changes

Backward Compatible

Platform

OS

  • NVPKCS11_AES_CTR_COUNTER_SIZE is renamed to NVPKCS11_AES_CTR_MAX_COUNTER_SIZE to reflect that the value is the maximum width (in bits) of the AES_CTR counter, since variable counter widths up to that maximum are now supported.

  • NVPKCS11_MAX_ENTRIES_PER_SHA_BATCH is renamed to NVPKCS11_MAX_ENTRIES_PER_DIGEST_BATCH to reflect that the same batch-entry limit applies across all digest mechanisms, not just SHA.

  • Both old names are moved into the nvpkcs11_legacy_public_macros group and are now defined as deprecated compatibility aliases for the new names. Existing code continues to compile but should migrate to the new names before the aliases are removed in a future release.

Yes

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Variable counter widths are now supported, so the new MAX_COUNTER_SIZE name communicates that the value is the maximum width rather than a fixed size. The mechanism-agnostic MAX_ENTRIES_PER_DIGEST_BATCH name reflects that the same batch-entry limit applies across all digest mechanisms.

Steps to Migrate

  1. Replace references to the deprecated counter-size macro:

    uint32_t counter_bits = NVPKCS11_AES_CTR_COUNTER_SIZE;

    uint32_t counter_bits = NVPKCS11_AES_CTR_MAX_COUNTER_SIZE;

  2. Replace references to the deprecated digest-batch macro:

    CK_ULONG max = NVPKCS11_MAX_ENTRIES_PER_SHA_BATCH;

    CK_ULONG max = NVPKCS11_MAX_ENTRIES_PER_DIGEST_BATCH;

PKCS#11 Library Implementation Version Macro#

Target Changes

Backward Compatible

Platform

OS

NVPKCS11_GETINFO_LIBRARYVERSION_MAJOR, reported by C_GetInfo in CK_INFO.libraryVersion.major, is 0x48 in 7.2.5.0 versus 0x41 in 6.5.4.2 — the value incremented across multiple releases between those endpoints, not in a single bump within 7.2.5.0 (within 7.2.5.0 itself only the minor version moved, 0x04 to 0x05). Callers that compare against a hardcoded numeric literal will see a different result anywhere along the 6.5.x to 7.2.5.0 range.

No, when compared against a hardcoded numeric literal; Yes, when compared against the symbolic macro.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

The library implementation version reflects accumulated changes across multiple releases. This entry is about how callers should read the value, not a single-release event.

Steps to Migrate

Compare against the symbolic macro instead of a hardcoded numeric value:

if (info.libraryVersion.major == 0x41) { /* expected */ }

if (info.libraryVersion.major == NVPKCS11_GETINFO_LIBRARYVERSION_MAJOR) {
    /* expected */
}

Expanded Return-Code Surface for Batch APIs#

Target Changes

Backward Compatible

Platform

OS

  • C_NVIDIA_BatchSignMessage, C_NVIDIA_BatchVerifyMessage and C_NVIDIA_BatchDigest now document CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED as a possible per-entry return value (assigned to each batch entry’s rv before the batch is submitted, so any unprocessed entry surfaces as this code rather than CKR_OK on partial-batch failures). The CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED constant itself already existed in 6.5.4.2.

  • The documented @retval surface of C_NVIDIA_BatchDigestInit grew to include CKR_DEVICE_REMOVED, CKR_FUNCTION_CANCELED, CKR_FUNCTION_FAILED and CKR_PIN_EXPIRED.

  • The documented @retval surface of C_NVIDIA_BatchDigest grew to include CKR_DEVICE_REMOVED, CKR_FUNCTION_CANCELED, CKR_FUNCTION_FAILED, CKR_HOST_MEMORY and CKR_OPERATION_ACTIVE.

  • C_NVIDIA_BatchDigestInit’s brief now also explicitly states that calling it while a digest process is active fails with CKR_OPERATION_ACTIVE.

No. The source rebuilds, but runtime behavior changed.

SR

QNX

Migration Path

  • Orin to Thor

Migration Release Path

  • 6.5.4.2 to 7.2.5.0

Migration Rationale

Brings the documented contract in line with the underlying implementation: the per-entry rv assignment for CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED is now part of the published return surface, and gaps in the previously published @retval list for C_NVIDIA_BatchDigestInit and C_NVIDIA_BatchDigest have been closed.

Steps to Migrate

  1. CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED is not a benign return value to skip past — the implementation assigns it to every entry’s rv before submitting the batch, so any entry that still carries the value after the call returns was never processed by the implementation (typically because an earlier entry failed and the batch was aborted). Callers that scan per-entry rv fields should treat it as a partial-batch-failure indicator, not as a success synonym:

    // Wrong — suppresses the not-processed sentinel and masks real partial failures.
for (CK_ULONG i = 0; i < count; ++i) {
    if (entries[i].rv != CKR_OK &&
        entries[i].rv != CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED) {
        /* handle */
    }
}

    // Right — surface unprocessed entries so the caller can decide
// whether to retry, abort, or report.
for (CK_ULONG i = 0; i < count; ++i) {
    switch (entries[i].rv) {
        case CKR_OK:                                  /* processed OK */
            break;
        case CKR_NVIDIA_ENTRY_PARSED_NOT_PROCESSED:   /* never processed */
            /* retry / abort / report — do not suppress */
            break;
        default:                                      /* per-entry error */
            /* handle */
            break;
    }
}

  2. Callers that switch on the return codes from C_NVIDIA_BatchDigestInit and C_NVIDIA_BatchDigest and rely on a closed set of values should extend their handling to cover the newly documented codes:

    rv = C_NVIDIA_BatchDigestInit(hSession, &mech, 16);
switch (rv) { case CKR_OK: ... case CKR_OPERATION_ACTIVE: ... }

    rv = C_NVIDIA_BatchDigestInit(hSession, &mech, 16);
switch (rv) {
    case CKR_OK:                ...
    case CKR_OPERATION_ACTIVE:  ...
    case CKR_DEVICE_REMOVED:    ...
    case CKR_FUNCTION_CANCELED: ...
    case CKR_FUNCTION_FAILED:   ...
    case CKR_PIN_EXPIRED:       ...
}