fbnic supports applying firmware which may not be rolled back. This is
implemented in firmware however it is useful for the driver to know the
minimum supported firmware version. This will enable the driver validate
new firmware before it is sent to the NIC. If it is too old the driver can
provide a clear message that the version is too old.
Signed-off-by: Lee Trager <lee@trager.us>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
drivers/net/ethernet/meta/fbnic/fbnic_fw.c | 4 ++++
drivers/net/ethernet/meta/fbnic/fbnic_fw.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
index 3d9636a6c968..e4f72fb730a6 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.c
@@ -464,6 +464,7 @@ static const struct fbnic_tlv_index fbnic_fw_cap_resp_index[] = {
FBNIC_TLV_ATTR_U32(FBNIC_FW_CAP_RESP_UEFI_VERSION),
FBNIC_TLV_ATTR_STRING(FBNIC_FW_CAP_RESP_UEFI_COMMIT_STR,
FBNIC_FW_CAP_RESP_COMMIT_MAX_SIZE),
+ FBNIC_TLV_ATTR_U32(FBNIC_FW_CAP_RESP_ANTI_ROLLBACK_VERSION),
FBNIC_TLV_ATTR_LAST
};
@@ -586,6 +587,9 @@ static int fbnic_fw_parse_cap_resp(void *opaque, struct fbnic_tlv_msg **results)
if (results[FBNIC_FW_CAP_RESP_BMC_ALL_MULTI] || !bmc_present)
fbd->fw_cap.all_multi = all_multi;
+ fbd->fw_cap.anti_rollback_version =
+ fta_get_uint(results, FBNIC_FW_CAP_RESP_ANTI_ROLLBACK_VERSION);
+
return 0;
}
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
index a3618e7826c2..692dfd8746e7 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_fw.h
@@ -42,6 +42,7 @@ struct fbnic_fw_cap {
u8 all_multi : 1;
u8 link_speed;
u8 link_fec;
+ u32 anti_rollback_version;
};
struct fbnic_fw_completion {
@@ -122,6 +123,7 @@ enum {
FBNIC_FW_CAP_RESP_STORED_CMRT_COMMIT_STR = 0x10,
FBNIC_FW_CAP_RESP_UEFI_VERSION = 0x11,
FBNIC_FW_CAP_RESP_UEFI_COMMIT_STR = 0x12,
+ FBNIC_FW_CAP_RESP_ANTI_ROLLBACK_VERSION = 0x15,
FBNIC_FW_CAP_RESP_MSG_MAX
};
--
2.47.1
On 5/9/2025 5:21 PM, Lee Trager wrote: > fbnic supports applying firmware which may not be rolled back. This is > implemented in firmware however it is useful for the driver to know the > minimum supported firmware version. This will enable the driver validate > new firmware before it is sent to the NIC. If it is too old the driver can > provide a clear message that the version is too old. > This reminds me of the original efforts i had with minimum firmware versions for the ice E810 hardware. I guess for fbnic, you entirely handle this within firmware so there's no reason to provide an interface to control this, and you have a lot more control over verifying that the anti-rollback behavior is correct. The definition for the minimum version is baked into the firmware image? So once a version with this anti-rollback is applied it then prevents you from rolling back to lower version, and can do a verification to enforce this. Unlike the similar "opt-in" behavior in ice which requires a user to first apply a firmware and then set the parameter, opening up a bunch of attestation issues due to not being a single atomic operation.
On 5/12/25 11:47 AM, Jacob Keller wrote: > > On 5/9/2025 5:21 PM, Lee Trager wrote: >> fbnic supports applying firmware which may not be rolled back. This is >> implemented in firmware however it is useful for the driver to know the >> minimum supported firmware version. This will enable the driver validate >> new firmware before it is sent to the NIC. If it is too old the driver can >> provide a clear message that the version is too old. >> > This reminds me of the original efforts i had with minimum firmware > versions for the ice E810 hardware. > > I guess for fbnic, you entirely handle this within firmware so there's > no reason to provide an interface to control this, and you have a lot > more control over verifying that the anti-rollback behavior is correct. > > The definition for the minimum version is baked into the firmware image? > So once a version with this anti-rollback is applied it then prevents > you from rolling back to lower version, and can do a verification to > enforce this. Unlike the similar "opt-in" behavior in ice which requires > a user to first apply a firmware and then set the parameter, opening up > a bunch of attestation issues due to not being a single atomic operation. Correct this is handled entirely in firmware. We use the normal firmware update process when incrementing anti-rollback. During the updating process firmware first validates that the new version number is >= to the anti rollback version set in the SOTP. If not the update is rejected. The drivers role is purely informational, it checks anti roll back and provides devlink with a human readable error when necessary. When incrementing anti rollback the NIC first boots the new firmware. Once it has validated it can boot the new firmware it increments the anti roll back version in the SOTP automatically. This makes anti roll back automatic and provides a way for us to abort the process if needed.
On Fri, May 09, 2025 at 05:21:14PM -0700, Lee Trager wrote: > fbnic supports applying firmware which may not be rolled back. This is > implemented in firmware however it is useful for the driver to know the > minimum supported firmware version. This will enable the driver validate > new firmware before it is sent to the NIC. If it is too old the driver can > provide a clear message that the version is too old. > > Signed-off-by: Lee Trager <lee@trager.us> > Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org>
© 2016 - 2025 Red Hat, Inc.