topic Re: Secure Boot support for Alletra 6k dHCI in HPE Alletra Storage

Secure Boot support for Alletra 6k dHCI

jlangmead — Thu, 07 Mar 2024 09:57:37 GMT

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

Re: Secure Boot support for Alletra 6k dHCI

giladzzz — Thu, 07 Mar 2024 08:26:55 GMT

talk to Nimble support they should have an answer.

Regards

Re: Secure Boot support for Alletra 6k dHCI

BoonL — Tue, 12 Mar 2024 06:18:20 GMT

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

Betreff: Secure Boot support for Alletra 6k dHCI

WissfeldA — Tue, 01 Oct 2024 18:24:11 GMT

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:

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.
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.
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**.
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).
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

Betreff: Secure Boot support for Alletra 6k dHCI

LuisSoares — Fri, 14 Feb 2025 03:45:07 GMT

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

Betreff: Secure Boot support for Alletra 6k dHCI

BoonL — Fri, 14 Feb 2025 09:38:35 GMT

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

Betreff: Secure Boot support for Alletra 6k dHCI

OmarM21 — Thu, 20 Feb 2025 07:02:37 GMT

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!!!!