Storage Concepts and Objects

Intel AMT Features > Storage Administration and Operations > Detailed Description > Storage Concepts and Objects

Storage Concepts and Objects

This section describes the concepts and objects used by the Intel AMT Storage feature to provide the 3PDS functionality.

Application

The name of an application program that uses 3PDS. There are two kinds of applications:

• Partner application: These are applications known when the firmware image is burned (such as through an agreement between an ISV and an OEM). Partner applications are allowed to use the space allocated to them, as well as space for non-partner applications if such space is available. Also, an administrator can change the total space allocated to each application individually.

• Non-partner application: These applications are not partners: they may only use space from the non-partner area of storage, and the administrator can only change the total space for all non-partner applications, not for individual applications.

Vendor

The creator of an application. The idea is that one vendor (ISV) may have multiple applications that wish to use 3PDS.

Enterprise

An enterprise serves as the “umbrella” for vendors and their applications. Although not required, the enterprise and the vendor names are usually identical. The enterprise must have been created (i.e., must have an EACL) before applications can be registered using it.

UUID (a GUID)

Used to distinguish between different instances of an application.

Enterprise Allocation Control List (EACL) Entry

The name of an Enterprise which can have vendors and applications associated with it.

• The EACL entry must be created before any applications can be registered under it.

• The EACL entry cannot be removed until all applications under it have been removed first.

• There is a limit of four enterprises total.

Factory Partner Allocation Control List (FPACL) Entry

This item provides the vendor name, the application name, and the total number of bytes that the application is allowed to use. Although the method that creates it allows supplying an “is partner” Boolean value, it should always be one (true).

The total number of entries in the FPACL list is 24

Non-partner Allocation Control List (NACL)

This represents the same information for a non-partner application as an FPACL does for a partner application. An entry in the list is created automatically when a non-partner application registers. It cannot be manipulated separately (unlike the FPACL, which can be), however, all the NACL entries are returned together with the FPACL entries from the Admin: Enumerate all Partner Application’s FPACL Entries flow.

Block

This is a collection of data created by the application. The block size should be a multiple of 4K bytes. The size cannot be changed once the block is created. The block is more or less like a file in a regular file system. Blocks have the following attributes:

• Name: A string naming the block.

• Hidden: Whether the block can be seen by other applications or not. If the block is not hidden, then permissions groups associated with the block are used to determine what another application can do with the block.

• Block Permissions Groups: A specification of what other applications can do with this application’s block. There can be up to two permissions groups associated with a block. NOTE: Permissions groups are associated with one and only one block. A permissions group contains:

• Permission: The permission specification (read-only or read-write).

• Name: The name of the permissions group

• Applications list: A list of application handles (up to 8) to whom the permission applies. One of these handles can be one of the following special “filter” values:

Value	Value
ISVS_APPLICATION_NAME_FILTER 0xFFFFFFF0	This is for applications with the same enterprise / vendor / name but with different UUIDs. The idea is that an application (4 –tuple: enterprise / vendor / name / UUID) creates and owns the block, but allows other applications with the same enterprise / vendor / name to access the block according to the permission. Applications can get a list of handles for other applications with the same vendor name and thus access their blocks that way
ISVS_VENDOR_NAME_FILTER 0xFFFFFFF1	This is for all applications with the same vendor name

• Actions: Once you have a block, you can perform the following actions:

Action	Description
Read	Read data from the block. No more than the Maximum Transmission Unit (MTU) bytes can be read in one operation. The MTU value can be obtained via a separate call.
Write	Write data to the block. The MTU restriction applies here also
Lock	Lock the block; this prevents it from being read or written by more than one application at a time.
Unlock	Unlock the block. There is a timeout on block locks (see Timeouts).

Sessions

In order to perform any 3PDS operation, a console or agent must open a session with Intel AMT. This happens when an application registers with the Intel AMT system. It gets back a session handle which is used in all subsequent operations. NOTE that this applies to storage operations only. Administration operations are performed directly and do not require an open session.

The maximum number of simultaneous sessions is 16.

Timeouts

Intel AMT times out the lock on a block and a session if there are no transactions according to the following:

• Locks on a block time out after 600 seconds.

• Sessions time out after 3600 seconds.

A function call exists to return the timeout values.

Handle

A handle is like a Unix/Linux file descriptor or a Windows handle. It is an integer value used to represent a given object within 3PDS. There are separate handles for: sessions, EACLs, FPACLs and NACLs, applications, blocks, and permissions groups associated with blocks. One or more handles are passed into storage operations and/or returned by them. Numeric zero can be a valid handle. Handle values are internal to each Intel AMT system.

Application Naming

For application naming, there is a hierarchy that makes up the full name: Enterprise + Vendor + Application name. This is vaguely similar to the familiar hierarchical file structure of an OS file system (directories + files) but is considerably more restricted than a regular OS file system.

Applications are created the first time they register with Intel AMT. They typically send the UUID of the system running the application and that UUID is stored in the flash data associated with the application. The UUID allows Intel AMT to distinguish different instances of the same application running on different consoles (or locally).

Applications with one enterprise/vendor/name can get the handles of other applications with the same enterprise/vendor/name but different UUIDs and thus access their blocks (from remote only).

Note:

When the ISVS_VENDOR_NAME_FILTER filter is used, Intel AMT only pays attention to the vendor name; the enterprise name can be different.