Message-ID: <b3b23f47-96d0-4cdc-a6fd-f7dd58a5d3c6@linux.intel.com>
Date: Wed, 11 Dec 2024 13:15:06 +0100
From: "Szapar-Mudlaw, Martyna" <martyna.szapar-mudlaw@...ux.intel.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, andrew+netdev@...n.ch, horms@...nel.org,
 jiri@...nulli.us, stephen@...workplumber.org, anthony.l.nguyen@...el.com,
 jacob.e.keller@...el.com, przemyslaw.kitszel@...el.com,
 intel-wired-lan@...ts.osuosl.org
Subject: Re: [RFC 0/1] Proposal for new devlink command to enforce firmware
 security



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

Powered by blists - more mailing lists