Message-ID: <20241209131450.137317-2-martyna.szapar-mudlaw@linux.intel.com>
Date: Mon,  9 Dec 2024 14:14:50 +0100
From: Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@...ux.intel.com>
To: netdev@...r.kernel.org,
	andrew+netdev@...n.ch,
	horms@...nel.org,
	jiri@...nulli.us,
	stephen@...workplumber.org
Cc: anthony.l.nguyen@...el.com,
	jacob.e.keller@...el.com,
	przemyslaw.kitszel@...el.com,
	intel-wired-lan@...ts.osuosl.org,
	Martyna Szapar-Mudlaw <martyna.szapar-mudlaw@...ux.intel.com>
Subject: [RFC 0/1] Proposal for new devlink command to enforce firmware security

RFC: Proposal for new devlink command to enforce firmware security

This RFC proposes addition of a new command to devlink API, providing a
mechanism to enforce secure firmware versions at the user's request. 
The primary goal is to enhance security by preventing the programming
of firmware with a lower security revision value. This feature is
particularly needed for Intel ice driver (and some other Intel drivers
next) but will be generic enough for other drivers to implement as well
for their purposes. Additionally, it proposes displaying the running
firmware security revision value and the set firmware minimum security
revision value in the output of the `devlink dev info` command for
Intel ice driver. 

Motivation

The E810 Ethernet controller provides a mechanism to prevent
downgrading to firmware versions containing known security
vulnerabilities. Specifically, the NVM components are signed
with a security revision, E810 ensures that components with
a lower security revision than the defined minimum cannot be loaded
onto the device.
Intel customers require that this action is not autonomous. Customers
typically uses this feature only in the target deployments after
finalizing testing of the new FW version. Autonomous action would
require manufacturer direct access to card to downgrade image to
previous stable version. By allowing the driver and user to manage the 
firmware security revision value, we can provide a flexible and secure
solution.
Additionally, displaying the current and minimum security revision
values in the `devlink dev info` command output will provide better
visibility and management for users.

Initial proposal for Minimum Security Revision update, via dedicated
parameter, was initially part of first devlink update deployment,
mechanism was questioned by community members [1]. However, Intel
still needs this functionality thus we are proposing a different
approach now to address the concerns raised previously. (In the last
community proposal, community proposed to make a decision based on
FW image - instead of dedicated parameter.)

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.


Example usage:

$ devlink dev info pci/0000:b1:00.0

pci/0000:b1:00.0:
  driver ice
  serial_number 00-01-00-ff-ff-00-00-00
  versions:
      fixed:
        fw.mgmt.min.srev 8
        fw.undi.min.srev 8
      running:
        fw.mgmt.srev 9
        fw.undi.srev 9
        

$ devlink dev lock-firmware pci/0000:03:00.0

WARNING: This action will prevent downgrades to versions with lower the
security version Are you sure you want to lock the firmware on device %s?. (y/N)
>y

$ devlink dev info pci/0000:03:00.0

pci/0000:03:00.0:
  driver ice
  versions:
      fixed:
        fw.mgmt.min.srev 9
        fw.undi.min.srev 9


This feature is essential for the `ice` Ethernet driver (and other
Intel drivers next) but is designed to be generic for other drivers
to implement. Feedback and suggestions are welcome.

[1] https://lore.kernel.org/netdev/20210203124112.67a1e1ee@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#u


Martyna Szapar-Mudlaw (1):
  devlink: add new devlink lock-firmware command

 include/net/devlink.h        |  2 ++
 include/uapi/linux/devlink.h |  2 ++
 net/devlink/dev.c            | 13 +++++++++++++
 net/devlink/netlink_gen.c    | 18 +++++++++++++++++-
 net/devlink/netlink_gen.h    |  4 +++-
 5 files changed, 37 insertions(+), 2 deletions(-)

-- 
2.47.0

Powered by blists - more mailing lists