Common Data Security Architecture (CDSA) White Paper

50 Chapter1

Introduction to Add-in Modules

* a module to identify itself when it sets an error.

* an application, to identify the requested module when attaching an add-in module.

For each bundled module, HP provides a GUID in /var/cdsa/cssm. Existing GUIDs and their

associated shared libraries are also speciﬁed in cdsa/hpguids.h.

Here is a sample GUID:

String*Location: /usr/lib/libcsp.1

String*Name: CDSA Adaptation Layer CSP for the CSP Toolkit from Co. A

String*Version: 1.2

String*CompatibleCSSMVersion: 1.20

String*Description: CDSA Adaptation Layer CSP for the CSP Toolkit from Co. A

String*Vendor: Hewlett Packard

Binary*Flags: 0

Binary*ServiceMasks: 2

Binary*NumberOfServices: 1

Users can run the HP-UX uuidgen command to generate a GUID for new modules. For an

example showing the creation of a GUID and how to alias it, see “How to Create a CDSA

Add-In Module for HP-UX” on page 53.

Initializer

For each add-in library, an initialization routine is required to be invoked by the system

loader right after the library loads successfully. If the library is a CSP, the initializer performs

integrity checks and prepares for registration with the CSSM.

The initialization routine is also invoked right before the library is unloaded, during which

time it unregisters with CSSM.

The initializer performs two tasks:

• initialization

• termination

The main purpose of initialization is to perform the add-in self-check.

If the add-in module is a CSP, a sequence of self-checking is required. For other types of

add-ins (CL, TP, and DL), the routine can be simpler.

• If self-checking is not required, the initialization functions become null functions.