Symptom

These instructions are prepared for system x240 M5 only.  Support for Remote Physical Presence was added in UEFI C4E132H Revision 2.50.

To enable "Secure Boot" on a server, it is not necessary to physically open system or change any internal DIP switch settings. UEFI setup provides the capability to remotely  assert physical presence. Users may also manually set the DIP switch 6 bit 2 to hardware assert physical presence but it is not recommended to leave the physical presence asserted after the system has booted into an OS for security reasons.

Step 1:
Boot server into the UEFI Setup screen. Browse to system settings --> Security --> Physical Presence Policy Configuration.

In default mode, users should expect to see Physical Presence Policy enabled and grayed out. Users will see Physical Presence State = De-asserted. 
Note: If for any reason Physical Presence Policy is disabled, then the "toggle Remote Physical Presence Assert" tab will be grayed out. To proceed the policy, it will need to be first enabled. This will require setting the hardware physical presence by DIP switch 6 bit 2 and rebooting to setup. Then, you will be able to enable the Physical Presence Policy. 
This feature provides administrators with added security feature of disabling the Physical Presence Policy to prevent remote assertion of physical presence. For security reasons, once the policy is set to disabled, the hardware physical presence should be removed by turning off DIP switch 6 bit 2.  

Step 2: 
Scroll down to "toggle Remote Physical Presence Assert" and select it and hit enter key.
Users will see that the "physical Presence State" changes to asserted. Asserting and de-asserting does not require a reboot to take effect.

Step 3: 
Now press 'Esc' key back up one level and go to: Security > Secure Boot Configuration Tab.

You may need to press the Refresh Physical Presence state to display the current value of Physical Presence.

Now set security Boot Configuration --> Secure Boot is --> change from Disabled to Enabled.

Users will see a pop up prompt "Are you sure you want to Enable Secure Boot? Do you want to continue? Y/N << enter Y.

Step 4:
Now return to the Physical Presence Policy Configuration tab and again select --> "toggle Remote Physical Presence Assert" in order to De-Assert Physical Presence State.

Step 5:
Press the 'Esc' key to the top level of UEFI Setup, then save settings and reboot.

The same steps can also be used to disable secure boot.

Affected Configurations

The system may be any of the following Lenovo servers:

• Lenovo Flex System x240 M5 Compute Node, Type 9532, any model

This tip is not software specific.

This tip is not option specific.

The system has the symptom described above.

Workaround

Not applicable.

Additional Information

Secure boot is intended to ensure that all executed code is trusted and signed. In default mode, Lenovo firmware will signature-verify everything loaded in UEFI mode.

When Secure Boot is activated, it checks each piece of software, including the UEFI drivers (Option ROMs) and the operating system, against databases of known-good signatures. If each piece of software is valid, the firmware runs the software and the operating system. The Secure Boot function will thus prevent any adaptor card from booting that is found to contain ROM that does not match the expected signature.

Secure boot is only supported for UEFI boot mode and not legacy boot mode.

OEMs provide their drivers to Lenovo which are then included in the UEFI firmware. This includes the signature database (db), revoked signatures database (dbx), and the Key Enrollment Key database (KEK). These databases are stored on the flash at manufacturing time.  

The signature database and the revoked signatures database list the signers or image hashes of UEFI applications, operating system loaders (such as the Microsoft Operating System Loader, or Boot Manager) and UEFI drivers that can be loaded on the server, and the revoked images for items that are no longer trusted and may not be loaded.

The Key Enrollment Key database is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database. After these databases have been added, and after final firmware validation and testing, Lenovo locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a PK. The PK can be used to sign updates to the KEK or to turn off Secure Boot.

In general, there is a precedence order (most to least significant) of PK, KEK, db, dbx. That is:

- To update a KEK, you have to have a signature with the correct PK.

- To update a db or a dbx, you have to have a signature with the correct PK or KEK.

- A PK is required to enable Secure Boot.

The keys description is important to understand the modes we support. Secure Boot has two (2) modes: Standard and Custom.

Standard Mode allows a user to take advantage of certificates signed by Microsoft. These certificates allow UEFI to verify all option ROMs and OS are signed and valid. They include both Windows and third-party certificates for Linux. Essentially, we allow these defaults in secure boot certificates to be used in our standard mode. This includes the one PK, multiple KEK, db, and dbx.

Custom Mode allows a user to install their own set of keys. The specifications for Secure Boot state allow a boot to occur in Custom Mode without a PK. This allows an OS to enroll a new PK which would then be used to validate its own KEK, db, and dbx.

The default in Secure Boot Mode is Standard Mode and the default Secure boot is Disabled.

Physical Presence:
Physical Presence is a form of authorization to perform certain TPM functions. This authorization normally comes from the platform operator. For TPM 1.2 devices, the functions requiring physical presence are those that perform provisioning and re-provisioning operations such as allowing ownership and clearing ownership when the current owner authorization value is unknown. For TPM 2.0 devices, physical presence is associated with operations that require platform authorization but are initiated by the OS. Usually, platform authorization can only be given by firmware, not by the OS. There are two methods to provide physical presence authorization: the command method and the hardware method. These two methods are defined for TPM 1.2 devices in the TPM 1.2 Main Specification and for TPM 2.0 devices in the PC Client Platform TPM Profile Specification.

Hardware method to assert physical presence:
An example of an implementation of the hardware method is a DIP switch on the system board that is wired to a pin on the TPM. Setting the switch causes the pin to change the polarity and would cause the TPM to set its internal physical-presence flag. Using this hardware method, commands requiring the indication of physical presence could be executed at any time (in the pre-OS environment or from the OS environment) as long as the switch is set and, for TPM 2.0, platform authorization is available. This presents a security concern if the switch if left in the asserted position.

Command method to assert physical presence:
Providing a button or switch to the outside of the platform is not feasible in some cases due to cost, form factor, usage, or accessibility. For this reason, a second method of asserting physical presence called the command method is defined. For the command method, firmware presents a user interface (UI) to explain the operation that has been requested. A physically present user confirms or rejects the operation by pressing a key on the keyboard. The command method then authorizes the TPM command to be sent to the TPM. No further check for physical presence is done in the TPM. The TPM performs the TPM operation if the user confirmed it through the UI. One of the properties required of the indication of physical presence is, it must be done by the platform operator, typically the user, when physically present at the platform. This requires the command method to be restricted to only be available while the platform state can provide this assurance. This state usually exists during the boot to UEFI setup prior to the availability of a network stack and exposure to potential untrusted software.