Introduction:
This feature must provide complete isolation of secrets stored by independent consumers – under no circumstances should one consumer be able to access secrets stored by another consumer illegally.
This effectively implies an access scope on the user granularity – multiple users must be allowed to store their secrets (potentially with the same name) using this framework without any worry of clashes.
Starting with system firmware FW950 and HMC 9.2.950, the Platform KeyStore (PKS) feature creates an encrypted non-volatile store. This store provides logical partitions with additional capabilities to protect sensitive information.
This feature aims to enable user-space applications to exploit PKS. PKS is a hardware backed NVRAM that offers secured storage for sensitive material.
The Platform KeyStore is configured via the management console. The total per partition size of PKS available can be configured from 4K bytes to 64K bytes in increments of 1K. The value of 0 kilobytes (KB) indicates that the keystore function is disabled for the logical partition.
Changes to the PKS configuration can be made after creation but there are a few limitations:
- This size of PKS can be increased to the maximum allowed while the partition is powered off, but reducing the size is not allowed.
- To disable PKS on a partition, the requested size should be set to 0. This operation will be blocked by PowerVM if it detects existing objects in storage. PKS can be disabled while the partition is running but it cannot be re-enabled.
PKS for User-Space overview:
- New administration utility introduced – ‘pksctl’.
- This feature is disabled by default, even if PKS is enabled from the HMC. It can be enabled using the ‘pksctl’ utility.
- To use this feature, one must first set the storage split between kernel and user-space using the `pksctl` utility.
- User-space storage allowed to be used is restricted to a maximum of 60% of the allocated PKS NVRAM storage size.
- User-space quota is split into two attributes that every registered user has - a minimum (guaranteed) and a maximum (glass ceiling) value.
- Maximum object size allowed to be stored through the framework is capped at 2048B (2kB).
- There will be a minimum storage overhead for every object that is written in the PKS NVRAM storage using pksctl utility.
Configuring PKS:
Default PKS state in HMC:

Kernel extension ‘pksus’ should be unloaded.

Error while running pksctl command.

Enable PKS when LPAR is running

Enable PKS from HMC console.
Shutdown Partition:

Configure PKS, save and activate partition:

After reboot check ‘pksctl’ status:

The ‘pksctl’ command options:
Sub-commands:

HELP option:
For ‘register’ sub-command:
Description: To add a new consumer.

For ‘deregister’ sub-command:
Description: To remove an existing consumer

For ‘stats’ sub-command:
Description: To query statistics about framework usage, or a registered consumer if specified

For ‘quota-shrink’ sub-command:
Description: To decrease the maximum quota for a specific consumer

For ‘quota-expand’ sub-command:
Description: To increase the minimum quota, maximum quota, or both for a specific user

For ‘set-default’ sub-command:
Description: To modify the default quota values for consumers to be registered in future. Also to modify the allocation split between ‘kernel’ and ‘user-space’.

For ‘purge’ sub-command:
Description: To clear out objects that are left over from prior installs

Working with ‘pksctl’:
On a system where PKS is freshly enabled with the below configuration:
Total Allocated PKS size: 64KB (4KB-64KB)
Default Split (kernel/user-space): 100% (Minimum split = 40%)
By default, this will be set to a 100-0 split, with 100% space reserved for the kernel space.
Allocation of storage up to 60% of the total available space can be done through the command
“pksctl set-default –default-split <value>”.
PKS storage status:

Let’s set the kernel-user usage split to 40-60:

After the split checking PKS storage status:

Checking the ‘pksctl’ stats:

The consumers and its configuration and objects are maintained in a consumer table in a file.

Register a consumer:

Consumers can also be registered with password being stored in a file.

Deregister a consumer:

Verify the user status in the file “/etc/security/pks”.

Shrink max-quota of a consumer:

Expand min/max quota of a consumer:

Check PKS statistics:

Set-default min/max:

Read/Write objects for a consumer and check the stats:
1. Register a consumer with name “user1”

2. Write an object of size 1024KB and perform read operation for the same object using APIs.
Sample C program:

3. Perform write operation with the above compiled program:

4. Write another object for ‘user1’:

Till max-quota which is 2KB, object has been stored in PKS for consumer ‘user1’.
As we can see there are four consumers existing out of which two objects (keys) are stored in PKS NVRAM of 1KB each, total 2KB storage used.
If incase ‘/etc/security/pks’ file gets corrupted or deleted due to re-installation or any other reason, the objects i.e. 2KB in this case will still be occupying the storage.
As the respective consumers of the keys are not existing the keys become invalid but will occupy the storage too. To clear those objects/keys the command used is - Purge.
Purge invalid security keys from PKS NVRAM:

References:
https://ibmdocs-test.dcs.ibm.com/docs/en/ssw_aix_73F_test?topic=p-pksctl-command – Web-link for the man page of ‘pksctl’ command.
https://www.ibm.com/docs/en/power10/9080-HEX?topic=partitions-enabling-platform-keystore-capability-logical-partition – Enable PKS
With this I end the document here. Happy reading folks! Please feel free to leave any queries or feedback in the comments. Our team will try to get back with the answers.