Message-ID: <30e3c7e7-c621-40b9-844c-d218fb3e9f2c@intel.com>
Date: Mon, 16 Dec 2024 16:09:12 +0100
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Jakub Kicinski <kuba@...nel.org>, "Szapar-Mudlaw, Martyna"
	<martyna.szapar-mudlaw@...ux.intel.com>, <andrew+netdev@...n.ch>
CC: <netdev@...r.kernel.org>, <horms@...nel.org>, <jiri@...nulli.us>,
	<stephen@...workplumber.org>, <anthony.l.nguyen@...el.com>,
	<jacob.e.keller@...el.com>, <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [RFC 0/1] Proposal for new devlink command to enforce firmware
 security

On 12/12/24 03:11, Jakub Kicinski wrote:
> On Wed, 11 Dec 2024 13:15:06 +0100 Szapar-Mudlaw, Martyna wrote:
>> This patch does not aim to introduce a new security mechanism, rather,
> 
> What I was referring to when I said "devlink doesn't have a suitable
> security model" is that we have no definition of what security guarantees
> we provide. Nothing in devlink is authenticated at all.
> 
> Anti-rollback is fundamentally about preventing FW compromise.
> How do you know that the FW is not compromised with devlink?

our FW (on-card little CPU) will reject a spooky FW image, only images
signed by Intel's priv key are accepted

> 
>> 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.
> 
> I know, I've heard it for my internal users too. Vendors put some
> "device is secure" checkbox and some SREs without security training
> think that this is enough and should be supported by devlink.
> 
>> 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.
> 
> Please point me to relevant standard that supports locking in security
> revision as an action separate from FW update, and over an insecure
> channel.
> 
> If you can't find one, please let's not revisit this conversation.

It's not standard, just the design for our e810 (e82x?) FW, but we could 
achieve the goal in one step, while preserving the opt-out mechanism for
those unwilling customers. I think that this will allow at least some
customers to prevent possibility of running a known-to-be-bad FW
(prior to opening given server to the world).

We could simply add DEVLINK_FLASH_OVERWRITE_MIN_VERSION (*) flag for the
single-step flash update [1], and do the update AND bump our "minsrev"
in one step.
The worst that could happen, is that customer will get some newer
version of the firmware (but a one released by Intel).
We preserve the simplicity of one .bin file with that too.

We will prepare a proper v2 of the RFC, reaching broader community,
but will check locally to see if there is a similar scheme in some
other intel (non eth) device first.
But please stop us if you believe that this idea is also
a phantasmagoria.

[1] https://docs.kernel.org/networking/devlink/devlink-flash.html
(*) name suggestions, as always, much welcomed

Powered by blists - more mailing lists