mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lee Trager <lee@trager.us>
To: Jacob Keller <jacob.e.keller@intel.com>,
	Alexander Duyck <alexanderduyck@fb.com>,
	Jakub Kicinski <kuba@kernel.org>,
	kernel-team@meta.com, "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Mohsin Bashir <mohsin.bashr@gmail.com>,
	Sanman Pradhan <sanman.p211993@gmail.com>,
	Su Hui <suhui@nfschina.com>, Al Viro <viro@zeniv.linux.org.uk>,
	Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 2/5] eth: fbnic: Accept minimum anti-rollback version from firmware
Date: Mon, 12 May 2025 17:59:35 -0700	[thread overview]
Message-ID: <98876971-e4e0-44f1-8faf-f791bd7a4e4e@trager.us> (raw)
In-Reply-To: <a406ecb3-a94d-47a7-bff8-becc6302a775@intel.com>

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.


  reply	other threads:[~2025-05-13  0:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-10  0:21 [PATCH net-next v4 0/5] eth: fbnic: Add devlink dev flash support Lee Trager
2025-05-10  0:21 ` [PATCH net-next v4 1/5] pldmfw: Don't require send_package_data or send_component_table to be defined Lee Trager
2025-05-12 14:32   ` Simon Horman
2025-05-12 18:42   ` Jacob Keller
2025-05-10  0:21 ` [PATCH net-next v4 2/5] eth: fbnic: Accept minimum anti-rollback version from firmware Lee Trager
2025-05-12 14:33   ` Simon Horman
2025-05-12 18:47   ` Jacob Keller
2025-05-13  0:59     ` Lee Trager [this message]
2025-05-10  0:21 ` [PATCH net-next v4 3/5] eth: fbnic: Add support for multiple concurrent completion messages Lee Trager
2025-05-12 14:33   ` Simon Horman
2025-05-10  0:21 ` [PATCH net-next v4 4/5] eth: fbnic: Add mailbox support for PLDM updates Lee Trager
2025-05-12 14:34   ` Simon Horman
2025-05-10  0:21 ` [PATCH net-next v4 5/5] eth: fbnic: Add devlink dev flash support Lee Trager
2025-05-12 14:31   ` Simon Horman
2025-05-12 18:48   ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98876971-e4e0-44f1-8faf-f791bd7a4e4e@trager.us \
    --to=lee@trager.us \
    --cc=alexanderduyck@fb.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=kernel-team@meta.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.swiatkowski@linux.intel.com \
    --cc=mohsin.bashr@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sanman.p211993@gmail.com \
    --cc=suhui@nfschina.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®