Secure Boot support for Alletra 6k dHCI

[jlangmead]

Hello guys,

i have a pair of new DL360 Gen11 hosts deployed at a customer site as part of a greenfield Alletra 6030 dHCI environment. Now i get the error "Host TPM attension alarm" in vCenter - which I generally expect.

Normaly i would acitvate Secure boot and all the TPM stuff needed to fix this. however, the hosts now PSOD stating the secure boot failed as it was unable to validate the signatures for the Nimble SCM vib(s)

Is there a workaround for this or is secure boot simply not an option for Gen11 hosts and we have to live with getting the Attestation alarm after every reboot?

thanks

[giladzzz]

Hi

talk to Nimble support they should have an answer.

Regards

[BoonL]

Download SCM from Infosight and reinstall the SCM. This should resolve the signature issue. 

[WissfeldA]

I know this is an old thread but i just had this issue today and  with a bunch of DL380 Gen11 and an Alletra 6k (6030) which had been "factory setup".
(We didnt do anything to the DL Compute nodes apart from racking the up and plugging them in - we assumed since that whole PCBE bundle was set up by the factory, things just work) - well ... assumptions in It don't go far

The errors were:

- vCenter Alarms/Warnings like :
   "Host TPM attestation alarm" or ""Unable to acquire ownership of TPM 2.0 device. Please clear TPM through the BIOS."

- Enabling Secure Boot in BIOS/RBSU leads to an ESX Pink Screen of death

It took me a whole day but I resolved it like this:

1. I first checked whether this ESX host was even capable of "Secure Boot" (which is a requirement of vSpheres TPM usage afaik) via SSH:
   > /usr/lib/vmware/secureboot/bin/secureBoot.py -c
   Secure boot CANNOT be enabled:
   Failed to verify signatures of the following vib(s): [HPE-Storage-Connection-Service HPE-Storage-psp].
   All tardisks validated. All acceptance levels validated.
   
   Which i've already seen on the Pink Screen, so i tried BoonL's suggestion.
2. So i downloaded HPE-Storage-Connection-Manager-for-VMware-7.0-7.0.2-700014.zip from https://infosight.hpe.com/  (Software Downloads), but not without checking the actual installed vibs with:
   > esxcli software vib list | grep HPE-Storage
   HPE-Storage-Connection-Service 7.0.2-700014   HPE   VMwareAccepted 2024-08-23  host
   HPE-Storage-psp                7.0.2-700014   HPE   VMwareAccepted 2024-08-23  host
   So the (factory preinstalled) version was 7.0.2-700014 ... strange - thats the current version.
3. Anyways - again thanks to BoonL - i just uploaded that zip to a datastore and uninstalled and reinstalled the VIBs:
   esxcli software vib remove --vibname=HPE-Storage-Connection-Service
   esxcli software vib remove --vibname=HPE-Storage-psp
   esxcli software vib install --depot=<full_path_to_file>/HPE-Storage-Connection-Manager-for-VMware-7.0-7.0.2-700014.zip
   Since no reboot was necessary, i checked again
   > /usr/lib/vmware/secureboot/bin/secureBoot.py -c
   Secure boot CAN be enabled.
   All vibs validated. All tardisks validated. All acceptance levels validated.
   
   Maybe someone with more knowledge than me can explain this.
   Anyways, now i was able to enable "Secure Boot" in RBSU and the ESXi booted up nicely, albeit the vCenter errors were still there.
   The Security Monitor on Datacenter level still read "Internal Error" ... **bleep**.
4. Many hours, trips to RBSU and reboots later i've stumbled across the RBSU Advanced TPM settings "TPM Storage Hierarchy" and "TPM Endorsement"
   and i remembered some *cough*competitors*cough* KB article about "TPM history" - how they called it ..
   I gave it a try and enabled both of them (dunno whether thats necessary).
5. This didn't instantly remediate the issue, but the vcenter logs at least didn't complain about "Internal Error".
   The last thing that we needed to do is to rediscover some TPM magick by just disconnecting and reconnecting the questionable host.
   Afterwards the errors/alarms/warnings were gone and the security state was "TPM attestation: passed"

I cannot explain, why this left the factory like this - imagine this system would have been shipped directly to the customer .... Big Frustration incoming !

Anyway .. maybe this helps someone in the future

TLDR:
- Reinstall SCM VIB (from infosight) on ESXi host (in maintenance mode)
- Reboot and enter RBSU
- Enable in RBSU: "Secure Boot", "TPM Endorsement", "TPM Storage Hierarchy", Save and Exit, then reboot
- When visible in vCenter, "Disconnect" and  "Connect" the host
- Clear TPM alarms
- Move on

[LuisSoares]

WissfeldA, you saved my day!  Your descirption of the problem and solution worked like a charm,.  Thank you so much!

Just wondering if the next DHCI 1-Click updates will break ESXi.

Maybe one thing to consider for future DHCI 1-Click updates is to go into the BIOS to disable secure boot temporarily before starting the DHCI 1-Click updates.

Thanks again!

Luis

[BoonL]

a) Arrays above 6.1.2.x would be able to handle servers with tpm enable. Earlier version of array OS, before 6.1.2.x, is not able to run SPP update when TPM is enabled. 

b) Advise against disabling TPM after secure boot has been enabled. That will likely lead to PSOD due to security violation.

https://knowledge.broadcom.com/external/article?articleNumber=312109

[OmarM21]

For me, Secure Boot was already enabled. And since this was a fresh install, I didn't remove SCM, and jumped right into enabling...

* Enable in RBSU: "Secure Boot", "TPM Endorsement", "TPM Storage Hierarchy", Save and Exit, then reboot

Upon reboot, the TMP message was gone! 

THANK YOU!!!!