Re: [RFC 0/1] Proposal for new devlink command to enforce firmware security

[Jakub Kicinski <kuba@kernel.org>]

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?

> 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.