|
|
Post by ueliyahu on Apr 24, 2023 10:08:54 GMT
Hi,
I read about SecureBoot 1.1.0 at DMFT documentation and want to add the support to the BMC.
There are few open questions that I didn't understood yet.
1. Secure boot scheme does not include settings URL (like Bios for example), what is the correct way to manage pending data base ?
2. Error handling question
What is the correct flow in case that illegal certificate/key posted by the user ? how to provide errors to the user ?
in such case next UEFI boot will fail ? and what next ? how should UEFI recover from such scenario ?
3. The document DSP0268_2022.3.pdf define three URLs for secure boot
What is the different between those URLs , all of the URLs provide the same contents ? (if so why three of them needed?)
/redfish/v1/CompositionService/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/SecureBoot
/redfish/v1/ResourceBlocks/{ResourceBlockId}/Systems/{ComputerSystemId}/SecureBoot
/redfish/v1/Systems/{ComputerSystemId}/SecureBoot
Thanks a lot
Uri
|
|
|
|
Post by mraineri on Apr 24, 2023 17:31:25 GMT
1) Any resource is allowed to implement its own Settings object. There is nothing that needs to be done in a schema file to specify that Settings is allowed. The Bios resource, for example, doesn't contain any "settings" definitions. However, given the interacting with the secure boot database is largely adding/removing certificates, you may not need a Settings object since the user will be performing POST and DELETE operations; instead, a task would be produced, and the task will complete after the next system reset. 2) There's some usage described here about this: redfishforum.com/thread/572/install-certificate-secure-boot. I wouldn't expect a failure to boot, but rather UEFI would reject the new certificate or signature, and then maintain its current configuration. 3) A ComputerSystem resource can be modeled in three locations depending on the usage. Both the CompositionService and ResourceBlocks usage is strictly for composable architectures where you have entire systems as building blocks for creating larger systems. If your usage is more of a traditional rackmount or blade server, then these do not apply to you, and you just need to focus for the usage beneath /redfish/v1/Systems. |
|
|
|
Post by ueliyahu on Apr 27, 2023 11:04:06 GMT
Thanks !
Regarding point number 1, not sure that I understood the part of "task would be produced".
If the out band user post new certificate to the DB and there is not "pending" values , so the new certificate will be part of the DB immediately at the BMC DBUS object , at the next reboot UEFI will validate the certificate and keep it. (is that the tasks that you meant for ? )
|
|
|
|
Post by mraineri on Apr 27, 2023 15:12:02 GMT
Depending on how your solution is designed, you might want to consider using a task for that very reason; you may have a need to let UEFI come up and process the certificate to ensure the client gets an acknowledgement that it was correctly installed in UEFI. For example, this could be the flow.
- User performs a POST to one of the certificate collections
- BMC processes the certificate and stores it internally for UEFI to consume on the next boot
- BMC responds with a 202 Accepted and creates a task
- At some point in the future, the client resets the system
- UEFI comes up, consumes the certificate and stores it in its own database
- BMC clears its copy of the certificate since UEFI successfully consumed it, marks the task from step 3 as complete
The above flow isn't required; perhaps UEFI's certificate database is solely owned by the BMC (and UEFI communicates with the BMC on every boot to extract its secure boot database information). A lot of these choices come down to design decisions for the overall solution. |
|
|
|
Post by jinder on Jun 6, 2023 16:03:13 GMT
Can the Redfish service have a Settings object in the CertificateCollection as another alternative? It would allow users to check the certificates that are going to be applied.
For example:
"/redfish/v1/Systems/system/SecureBoot/SecureBootDatabases/db/Certificates/" represents the current active certificate collection, which disallows users from POSTing and DELETing.
"/redfish/v1/Systems/system/SecureBoot/SecureBootDatabases/db/Certificates/Settings" represents the future certificate collection, which initially contains the same certificates as the active collection but allows users to POST and DELETE.
When UEFI initializes, it consumes the certificates from the Settings object and stores them in its own database.
|
|
|
|
Post by mraineri on Jun 6, 2023 16:11:30 GMT
No, a settings resource is only used to stage PATCH operations for a singular resource.
You could use the operations apply time annotation on collections for staging POST and DELETE requests; that term was created specifically for collection modifications and actions.
|
|
