On 12/10/2024 12:36 AM, Jakub Kicinski wrote:
On Mon, 9 Dec 2024 14:14:50 +0100 Martyna Szapar-Mudlaw wrote:
Proposed design
New command, `devlink dev lock-firmware` (or `devlink dev guard-firmware`),
will be added to devlink API. Implementation in devlink will be simple
and generic, with no predefined operations, offering flexibility for drivers
to define the firmware locking mechanism appropriate to the hardware's
capabilities and security requirements. Running this command will allow
ice driver to ensure firmware with lower security value downgrades are
prevented.
Add also changes to Intel ice driver to display security values
via devlink dev info command running and set minimum. Also implement
lock-firmware devlink op callback in ice driver to update firmware
minimum security revision value.
devlink doesn't have a suitable security model. I don't think we should
be adding hacks since we're not security experts and standards like SPDM
exist.
I understand that customers ask for this but "security" is not a
checkbox, the whole certificate and version management is necessary.
Hi Jakub,
Thank you for your response. Apologies if any of earlier wording was
unclear or poorly chosen.
While this feature is needed for security reasons, its implementation in
the kernel isn't directly tied to kernel/driver security.
The E810 Ethernet controller firmware provides a certain level of
security, which includes a mechanism to prevent firmware downgrades (to
past, less secure versions). However, it is the driver that needs to
initiate this mechanism. After "locking/fusing/freezing/guarding" (open
to name suggestions) the current firmware version, upgrades would still
be possible. The card itself handles firmware validation, including
verifying signatures and ensuring that only properly signed and accepted
firmware can be installed. Thus the firmware can only be upgraded to a
validated version that the card has approved.
This patch does not aim to introduce a new security mechanism, rather,
it enables users to utilize the controller's existing functionality.
This feature is to provide users with a devlink interface to inform the
device that the currently loaded firmware can become the new minimal
version for the card. Users have specifically requested the ability to
make this step an independent part of their firmware update process.
Leaving in-tree users without this capability exposes them to the risk
of downgrades to older, released by Intel, but potentially compromised
fw versions, and prevents the intended security protections of the
device from being utilized.
On the other hand always enforcing this mechanism during firmware
update, could lead to poor customer experiences due to unintended
firmware behavior in specific workflows and is not accepted by Intel
customers.
Devlink tool was proposed for this purpose, as it is designed for
administrative/root-level tasks such as this. Perhaps it would be more
appropriate to integrate the proposed implementation as a subcommand
(attribute) under the devlink flash API, which was the second considered
option, rather than keeping it as a separate devlink command?
Thank you and best regards,
Martyna
