On 5/8/21 5:32 AM, Carlos E. R. wrote:
On 08/05/2021 05.43, -pj wrote:
On 5/7/21 6:04 AM, Anton Aylward wrote:
On 2021-05-06 8:14 p.m., Carlos E. R. wrote:
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
indeed. Anything that Microsoft has 'touched' scares me. My implementation of Grub2 Trusted Boot Support on this laptop appears to me to function. Obviously I do not know any real details about the difference between Grub2 and Grub2 Trusted Boot Support. I would have never thought at a glance that Microsoft had involvement in the development of this. Thanks for your input on this matter.
Generally, people think that all that is a Microsoft thing. After all, the keys used by Linux have to vetted by Microsoft or something.
A quick search - the "microsoft" word appears many times in these two articles:
https://wiki.ubuntu.com/UEFI/SecureBoot https://en.opensuse.org/openSUSE:UEFI
Google "What is secure boot and trusted boot?"
http://cdn.openpowerfoundation.org/wp-content/uploads/resources/openpower-re...
"Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. ... Secure Boot prevents the system from executing either accidentally or maliciously modified firmware.Apr 19, 2018"
2.3. Trusted Boot and Secure Boot
Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. Trusted Boot artifacts can be used to remotely verify system integrity or to seal secrets to that they are only available after certain firmware has executed. Secure Boot is the cryptographic signing and verification of firmware boot components, failure of which is flagged for system administrator investigation and action, including logging an error and halting the system boot. Secure Boot prevents the system from executing either accidentally or maliciously modified firmware.
To achieve Trusted Boot and Secure Boot OpenPOWER Readiness, a system must:
1 Include a Trusted Platform Module (TPM), a small embedded security processor that conforms to the Trusted Computing Group TPM 2.0 specification that can securely store data.
2 Create a firmware measurement log and extend appropriate measurements to PCRs in the TPM as documented in the op-build source code and design documentation when in Trusted Boot mode.
3 Be able to store firmware components in Processor NOR (PNOR) flash memory that are packaged and signed in accordance with the op-build source code and design documentation, to support secure boot of firmware
4 Reserve a region in PNOR for storing OS-specific signatures and keys, to support secure boot of the target Operating System.
5 Provide a platform-specific method to assert physical presence to bypass Secure Boot for system recovery.
In order to use existing OpenPOWER firmware support:
1 The TPM processor should be compatible with the Nuvoton NPCT 650 and should be connected to the CPU via an I2C bus.
2 Firmware components must be packaged and signed in accordance with the op-build source code and design documentation. The foregoing applies to systems satisfying OpenPOWER Foundation Section 2.1, “ISA Profile rev 1.0.0 based systems” or Section 2.2, “ISA Profile rev 2.0.0 based systems”.
Systems capable of supporting Trusted Boot and Secure Boot for firmware and operating system integrity verification and protection are recommended. Thanks for the information on this.