Software and Firmware Upgrades
Your system consists of components that might, from time to time, require updating to newer versions. The newer version might have fixes or functional improvements that are useful or important for your application. The components that might be affected are:
>Client software. See Client Software Upgrades
>SafeNet Luna PCIe HSM firmware upgrades. See HSM Firmware Upgrades.
>SafeNet Luna Backup HSM firmware. See Upgrading the SafeNet Luna PCIe HSM or SafeNet Luna Backup HSM Firmware.
CAUTION! If you require that your SafeNet Luna PCIe HSM be FIPS-certified, you must use FIPS-certified firmware. Refer to Customer Release Notes for more information.
Client Software Upgrades
To upgrade the SafeNet Luna HSM Client software, first uninstall any previous version of the Client. Then, run the new installer the same way you performed the original installation (see SafeNet Luna HSM Client Software Installation in the Installation Guide).
The client uninstaller, when invoked on Windows, removes libraries, utilities and other material related to the client, but does not remove configuration files and certificates. This allows you to install the newer version and be able to resume operation without need to manually restore configuration settings and without need to recreate, re-exchange, and re-register client and appliance certificates for NTLS.
HSM Firmware Upgrades
NOTE It is strongly recommended that your SafeNet Luna PCIe HSM be powered from an uninterruptible power supply (UPS) when you perform the firmware update. There is a small chance that a power failure during the update command could leave your SafeNet Luna PCIe HSM in an unrecoverable condition.
Changing the Firmware Upgrade Permissions (Linux only)
By default, the root user and any user who is part of the hsmusers group can perform a firmware upgrade. You can restrict firmware upgrade operations to root only (that is, disable firmware upgrades for members of the hsmusers group), if desired.
To restrict firmware upgrade operations to the root user only:
1.Open the the /etc/modprobe.d/k7.conf file for editing:
sudoedit /etc/modprobe.d/k7.conf
2.Change the k7_rootonly_reset option from 0 to 1. Save the file and exit the editor.
3.Stop any processes that are using the K7 driver. Typically this means stopping the pedclient service, and the luna-snmp service, if you are using SNMP:
sudo systemctl stop pedclient_service
sudo systemctl stop luna-snmp
4.Reload the driver:
sudo systemctl reload k7
Upgrading the SafeNet Luna PCIe HSM or SafeNet Luna Backup HSM Firmware
To upgrade the firmware on a SafeNet Luna PCIe HSM or SafeNet Luna Backup HSM, use LunaCM on the SafeNet Luna HSM client computer that contains:
>the SafeNet Luna PCIe HSM or SafeNet Luna Backup HSM you want to upgrade.
>the firmware upgrade (.fuf) file with its associated firmware authentication code (.txt) file.
To upgrade the SafeNet Luna PCIe HSM or SafeNet Luna Backup HSM firmware:
1.Copy the firmware file (<fw_filename>.fuf) to the client root directory. Defaults are:
•Windows: C:\Program Files\SafeNet\LunaClient
•Linux: /usr/safenet/lunaclient/bin
2.Obtain the firmware authorization code:
a.Contact Thales Group Technical Support. The firmware authorization code is provided as a text file.
b.Copy the <fw_authcode_filename>.txt file to the client root directory. Defaults are:
•Windows: C:\Program Files\SafeNet\LunaClient
•Linux: /usr/safenet/lunaclient/bin
3.Launch LunaCM.
4.If more than one HSM is installed, note which slot is assigned to that HSM and select it.
slot set -slot <slot_number>
5.Login as HSM SO.
role login -name so
6.Enter the following command to upgrade the firmware on the HSM:
hsm updatefw -fuf <fw_filename>.fuf -authcode <fw_authcode_filename>.txt
Rollback Behavior
When rolling HSM firmware back to an earlier version, the order of the steps you perform is important.
An HSM that receives a firmware update arrives at that condition with any capabilities/features that were part of the HSM before the update was installed. The pre-update record of <firmware version+configuration> is set. If you rollback, you return the HSM to exactly the state that was recorded, prior to the update. All the same capabilities/features would be available, because they were present before the firmware update.
Any capability that you added after a firmware update would be lost, if you then rolled back the firmware, because the pre-update record of <firmware version+configuration> did not include any capability that you added only post-update. In that case:
>If the late-installed capability is not dependent on the newer firmware, then you can simply install it again, on the HSM at the rolled-back firmware version, and it will become part of the pre-update record the next time you update firmware.
>If the late-installed capability is dependent on the newer firmware, then you must do without that feature/capability until you once more update to a firmware version that can support it. At that time, you will need to re-install that capabilityupgrade.
The following table summarizes the options comparatively.
| Start with this |
If you do this... |
Result is this |
If you next do this... |
Result is this |
If you next do this... |
Result is this |
If you next do this... |
Result is this |
|
|---|---|---|---|---|---|---|---|---|---|
| Example 1 (Read across ==>) |
f/w X and Capabilities |
Update to f/w Y |
f/w Y and Capabilities |
Roll back to f/w X |
f/w X and Capabilities |
||||
| Example 2 (Read across ==>) |
Add Capability D (no dependency) |
f/w X and Capabilities |
Update to f/w Y |
f/w Y and Capabilities |
Roll back to f/w X |
f/w X and Capabilities |
|||
| Example 3 (Read across ==>) |
Update to f/w Y |
f/w Y and Capabilities |
Add Capability D (no dependency) |
f/w Y and Capabilities |
Roll back to f/w X |
f/w X and Capabilities |
|||
| Example 4 (Read across ==>) |
Capability E depends on f/w Y; Attempt to add Capability E fails |
f/w X and Capabilities |
Update to f/w Y |
f/w Y and Capabilities |
Add Capability E (depends on f/w Y) |
f/w Y and Capabilities |
Roll back to f/w X |
f/w X and Capabilities |
|
| In Example 1, no capabilities change; only the firmware version. | |||||||||
| In Example 2, D is added before firmware update; therefore the pre-update record includes capability D, so D survives firmware update and firmware rollback. | |||||||||
| In Example 3, D is added after firmware update, the pre-update record does not include capability D, so D does not survive firmware rollback. | |||||||||
| In Example 4, the pre-update record does not include capability E, so E does not survive firmware rollback. | |||||||||
