All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
To: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
	aleksandr.loktionov@intel.com
Subject: [PATCH iwl-next v3 0/2] ice: eRoT adapter NVM update guard
Date: Tue, 27 Oct 2026 18:45:00 +0100	[thread overview]
Message-ID: <cover.1793119681.git.aleksandr.loktionov@intel.com> (raw)

Parse the external Root of Trust capability and reject a PLDM capsule
that does not carry every component an eRoT adapter authenticates,
before any flash bank is erased.

Changes in this v3 respin:
  - Act on device capabilities read once per flash attempt instead of
    on the cached copy: a driver loaded while firmware was already in
    recovery mode has no cached capabilities, and a reset re-parses
    them in place. The same read feeds the pending update check that
    the attempt already makes, so an update still costs one List Device
    Capabilities round trip.
  - Reject duplicates and components without data while the component
    tables are sent, and require all four components before the first
    bank is erased and again before activation.
  - Name the components the way the user names them: fw.mgmt, fw.undi,
    fw.netlist, fw.pqc_manifest.
  - Document the invalid capability policy, and that the driver can
    neither activate nor roll back fw.pqc_manifest.
  - Report the new rejections through the netlink extended ACK only.
  - Drop __free(kfree) and the mid-function declaration.
  - One errno for a malformed image, and -EIO for an invalid capability
    value instead of -EOPNOTSUPP.
  - Make the capability verdicts sticky, so a duplicated capability
    entry cannot undo an earlier one.
  - Shorten both commit messages and the devlink section. The review
    tags from earlier rounds are not carried, since the update path
    changed; a fresh review is requested.

On the Manifest: the AQ activation select mask and the pending update
capabilities have no Manifest entry, so the driver writes that bank and
requests no activation for it. It can neither activate nor roll back
the bank, and the devlink docs now say so. Two points still need an
answer from the firmware side, and a Tested-by from a named adapter
would carry the rest: whether shadow RAM word 0x4E and component ID
0x12 are the right values for the PQC Manifest, and whether the eRoT
authenticates a Manifest against the active image, which decides
whether writing it before the other banks are activated is safe.

Two defects next to this path are not part of this series because they
predate it: an ice_aq_task left linked in pf->aq_wait_list when an AQ
command submission fails, because ice_aq_prep_for_event() has no undo
helper, and unchecked lengths in lib/pldmfw (a 32-bit size_t wrap in
pldm_check_fw_space(), and a component bitmap whose length is never
checked against the component count). Fixes go out separately; the new
module type ID only widens the first one.

Aleksandr Loktionov (2):
  ice: parse external Root of Trust capability
  ice: reject partial NVM update on eRoT adapters

 Documentation/networking/devlink/ice.rst      |  24 +++
 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |   1 +
 drivers/net/ethernet/intel/ice/ice_common.c   |   7 +
 .../net/ethernet/intel/ice/ice_fw_update.c    | 193 +++++++++++++++---
 drivers/net/ethernet/intel/ice/ice_type.h     |   4 +
 include/linux/net/intel/libie/adminq.h        |   1 +
 6 files changed, 203 insertions(+), 27 deletions(-)

-- 
2.56.0


             reply	other threads:[~2026-10-27 17:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 17:45 Aleksandr Loktionov [this message]
2026-10-27 17:45 ` [PATCH iwl-next v3 1/2] ice: parse external Root of Trust capability Aleksandr Loktionov
2026-10-27 17:45 ` [PATCH iwl-next v3 2/2] ice: reject partial NVM update on eRoT adapters Aleksandr Loktionov
2026-10-28 12:11   ` Przemek Kitszel

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=cover.1793119681.git.aleksandr.loktionov@intel.com \
    --to=aleksandr.loktionov@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.