Purpose

In general, communications between a host application and a custom firmware module is over both packet and byte-oriented physical media (Ethernet and PCIe bus), using well-formed byte buffers.

A host application identifies which HSM function a byte buffer should be routed to, by supplying a module's Module ID (mID), the specific method's sub-function code (SFC), and the byte buffer itself to the SecurityServer API library's .exec(...) method.

The SDK documentation and examples demonstrate construction and manipulation of these byte buffers manually. The tools described here are _code generation tools_, designed to generate all the byte buffer construction and manipulation up front, and automatically, based on user input.

This is done through the compilation of a simple `pattern`, as used by cmds_scanf (discussed later). Alternately, these patterns can be derived from other input formats (IDL, XML, etc), however the primary tool, "SFCBuffers" ingests cmds_scanf patterns. Additional tooling (for non-standard input formats) are provided to consume the other formats, but generate the necessary pattern and supporting fields into the standardized format, for compilation by SFCBuffers.

The string 'u4v1c32v2u4' is an example pattern, suitable for use by SFCBuffers.

As a pattern is compiled, the tools will generate:

  • Host source (C++ and Java) classes (OOP) based on the pattern. The OOP classes compute serialized length of, and will serialize and deserialize byte buffers based on the pattern,

  • Host source test libraries that demonstrate use of the OOP classes,

  • A complete SDK "external SFC" method stub, that uses SDK-standard methodology to parse the incoming byte buffer for use by the method,

  • C library code that computes serialized length of, and will serialize and deserialize byte buffers based on the pattern,

  • Lua code that serializes and deserializes byte buffers based on the pattern, and

  • Additional code artifacts, libraries and how-to documents that assist in development.