Add EOL support for iMX8#51
Conversation
On some platforms, such as imx8x, an authenticated message is necessary to advance the life cycle to EOL. Prepare the EOL SLC API's to receive such a message. For imx8x, knowing the length of the message is not strictly necessary as it will just relay this message to the SCU and eventually the SECO. For future purposes, a length argument might be necessary. Therefore, add it right away.
The SECO is able to provide additional events which may contain things such as extended error codes to previous RPC calls. It's quite rough on the edges as the documentation states that it has a fixed number of events it can store and once the maximum number of events have been reached, it will no longer store any more events. The event codes are still useful in some cases for debugging purposes. Add support for reading the last recorded event.
Some RPC calls, such as return_lifecycle takes an address as argument. These addresses must be readable from the SCU's point of view. Add a mapping to "Secure RAM" to be able to send authenticated messages to the SCU.
Add support for advancing to EOL/Return Lifecycle
Some platforms require a authentication message in order to advance to EOL lifecycle. Add an optional argument to support this.
If the SECO is unable to provide the current life cycle, take the safe route and panic as the result is used to determine whether or not authentication is needed for command mode.
for more information, see https://pre-commit.ci
thebolt
left a comment
There was a problem hiding this comment.
Some of the pre-commit fixes should be squashed into the commit that introduces the problems instead of having a separate "fixup" commit. There are also a number of pre-commit issues not fixed.
| self.pb_s.slc_set_configuration_lock() | ||
|
|
||
| def slc_set_end_of_life(self) -> None: | ||
| def slc_set_end_of_life(self, file: pathlib.Path) -> None: |
There was a problem hiding this comment.
As the data included here is a small amount of (binary) data, it would make more sense from an API perspective to have data: bytes | None and then pass the data buffer into the underlaying C API. The Click-based tooling can/should read it from a file, but enforcing a file on API level seems unnecessarily restrictive.
| if (err != SC_ERR_NONE) { | ||
| LOG_ERR("Failed to read life cycle (%i), resetting...", err); | ||
| plat_reset(); | ||
| while(1); | ||
| } |
There was a problem hiding this comment.
To me it seems to be the wrong abstraction level to make a reset initiation.. Rather return an error from this method and put the policy in the calling method (such as where authentication is checked). If it should reset when determining authentication mode or just default to require authentication.. both could be argued but the latter is probably safer.
No description provided.