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
