fw-update: reject mismatched EID in ItemUpdateManager dispatch

ItemUpdateManager::handleRequest declared its eid parameter as
mctp_eid_t /*eid*/ and dispatched purely on command. Combined with
AggregateUpdateManager iterating updateManagers in SoftwareIdentifier
(i.e. eid-then-component) order, whichever active ItemUpdateManager
came first claimed every FW-update response regardless of the inbound
EID. Two concurrent target updates on different EIDs would have all
responses funneled to the lower-EID manager.

Concretely: with an update on EID 12 in flight, starting an update
on EID 10 created ItemUpdateManager(10). EID 12's apply_complete was
then consumed by deviceUpdater10 and logged as if it belonged to EID
10 (device_updater.cpp:858 uses the deviceUpdater's own eid member).
EID 10 timed out on ActivateFirmware while EID 12's deviceUpdater
state was corrupted by the misrouted messages.

The per-ItemUpdateManager state (deviceUpdater, packageMap, dupFd,
inProgressActivation, ...) is already independent, and the shared
Handler<Request>/InstanceIdDb demux BMC->FD responses by
(eid, instanceId), so concurrent multi-EID target updates work
correctly once the responder path stops the cross-EID misrouting.

Add an explicit eid != this->eid early-return that yields
PLDM_FWUP_COMMAND_NOT_EXPECTED, letting AggregateUpdateManager fall
through to the next manager. Fold the !deviceUpdater branch into the
same early-return since it returns the same encoded response, and
convert the placement-new calls to std::start_lifetime_as<> to match
the rest of the codebase.

Tested on nvl32-obmc:
- Full bundle multipart update.
- Single target update.
- Back to back single-target updates.
- Full bundle update followed by a target update (previously flooded
  the journal with "invalid state when updating progress" and served
  data from the stale bundle DeviceUpdater; now routed correctly).
- Target update on a second PLDM device while an update on another
  device is in progress: both complete successfully.
- Target update on the same device while its update is in progress:
  rejected as expected.

Signed-off-by: Dhruv Rathi <rathidhruv04@gmail.com>
Change-Id: I390c54c82fc6405de37a06af6a8d0e80d31735d3
1 file changed
tree: f3e7f3ec0542869ec489d9712bcd782546b22dab
  1. common/
  2. configurations/
  3. docs/
  4. fw-update/
  5. host-bmc/
  6. libpldmresponder/
  7. oem/
  8. platform-mc/
  9. pldmd/
  10. pldmtool/
  11. requester/
  12. softoff/
  13. subprojects/
  14. test/
  15. tools/
  16. utilities/
  17. .clang-format
  18. .clang-tidy
  19. .eslintignore
  20. .gitignore
  21. .linter-ignore
  22. LICENSE
  23. meson.build
  24. meson.options
  25. OWNERS
  26. README.md
README.md

PLDM - Platform Level Data Model

License

Overview

PLDM (Platform Level Data Model) is a key component of the OpenBMC project, providing a standardized data model and message formats for various platform management functionalities. It defines a method to manage, monitor, and control the firmware and hardware of a system.

The OpenBMC PLDM project aims to implement the specifications defined by the Distributed Management Task Force (DMTF), allowing for interoperable management interfaces across different hardware and firmware components.

Features

  • Standardized Messaging: Adheres to the DMTF's PLDM specifications, enabling consistent and interoperable communication between different components.
  • Modularity: Supports multiple PLDM types, including base, FRU,Firmware update, Platform Monitoring and Control, and BIOS Control and Configuration.
  • Extensibility: Easily extendable to support new PLDM types and custom OEM commands.
  • Integration: Seamlessly integrates with other OpenBMC components for comprehensive system management.

Getting Started

Prerequisites

To build and run PLDM, you need the following dependencies:

  • Meson
  • Ninja

Alternatively, source an OpenBMC ARM/x86 SDK.

Building

To build the PLDM project, follow these steps:

meson setup build && meson compile -C build

To run unit tests

The simplest way of running the tests is as described by the meson man page:

meson test -C build

Alternatively, tests can be run in the OpenBMC CI docker container using these steps.

To enable pldm verbosity

pldm daemon accepts a command line argument --verbose or --v or -v to enable the daemon to run in verbose mode. It can be done via adding this option to the environment file that pldm service consumes.

echo 'PLDMD_ARGS="--verbose"' > /etc/default/pldmd
systemctl restart pldmd

To disable pldm verbosity

rm /etc/default/pldmd
systemctl restart pldmd

Documentation

For complete documentation on the functionality and usage of this repository, please refer to the docs folder.