[Bug]: IPMI SSIF Multi-part Read Middle incorrectly expects Block Number to start at 1

[jls5177]

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

According to the SSIF spec, the BMC Multi-part Read Middle should start with block number equal to 0.

However, the current code is expecting the first "middle" response to have a block number that starts at 1: https://github.com/microsoft/mu_feature_ipmi/blob/main/IpmiFeaturePkg/Library/IpmiTransportLibSsif/Ssif.c#L189C1-L196C8

// set when parsing the Multi-part "start" response
BlockNumber     = 0;

// executed when the "middle" response is received
if (BlockBuffer[0] != BlockNumber + 1) {
   // out-of-sequence error
}

BlockNumber = BlockBuffer[0];

This issue is not observed in Windows/Linux IPMI SSIF interfaces. We can review the Linux kernel SSIF driver to compare the behavior: https://github.com/torvalds/linux/blob/master/drivers/char/ipmi/ipmi_ssif.c#L710C1-L721C4

// set when parsing the Multi-part "start" response
ssif_info->multi_pos = 1;

// executed when the "middle" response is received
blocknum = data[0];
// ...
if (blocknum == 0xff) {
  // handle last "middle" packet
} else if (blocknum + 1 != ssif_info->multi_pos) {
   // out-of-sequence error
}

We can see the Linux kernel SSIF driver is setting the expected block number (blocknum) to 1 as it uses this to track outstanding multi-part reads. But then it compares the received block number (blocknum) to the expected blocknum but it increments by 1 to account for multi_pos not starting at 0.

Expected Behavior

The expectation is for the driver to align to the SSIF spec. This behavior ensures the same BMC firmware can work across all server environments (Windows, Linux, UEIF, BSD, ...).

Steps To Reproduce

1. Run IPMI SSIF request that generates a multi-part read from the BMC with a size of at least 33 bytes (e.g., reading the FRU).
2. If the BMC follows the spec: this will fail
3. If the BMC modified their code to support this UEFI specific behavior: this will succeed, but performing the same SSIF multi-part read from within Linux will fail.

Build Environment

- OS(s):
- Tool Chain(s):
- Targets Impacted:

Version Information

This issue is present in the default branch. I am unsure how far back this change goes.

Urgency

High

Are you going to fix this?

I will fix it

Do you need maintainer feedback?

Maintainer feedback requested

Anything else?

I've captured a Linux kernel trace log from a system with a BMC that aligns to this broken UEFI behavior which causes the Linux IPMI SSIF command to fail:

       kssif0010-1278    [002] ..... 268046.323474: smbus_read: i2c-0 a=010 f=0000 c=3 BLOCK_DATA
       kssif0010-1278    [002] ..... 268046.323478: i2c_write: i2c-0 #0 a=010 f=0000 l=1 [03]
       kssif0010-1278    [002] ..... 268046.323479: i2c_read: i2c-0 #1 a=010 f=0601 l=1
       kssif0010-1278    [002] ..... 268046.324301: i2c_reply: i2c-0 #1 a=010 f=0201 l=33 [20-00-01-**redacted**]
       kssif0010-1278    [002] ..... 268046.324303: i2c_result: i2c-0 n=2 ret=2
       kssif0010-1278    [002] ..... 268046.324306: smbus_reply: i2c-0 a=010 f=0000 c=3 BLOCK_DATA l=33 [20-00-01-**redacted**]
       kssif0010-1278    [002] ..... 268046.324307: smbus_result: i2c-0 a=010 f=0000 c=3 BLOCK_DATA rd res=0
       kssif0010-1278    [002] ..... 268046.324312: smbus_read: i2c-0 a=010 f=0000 c=9 BLOCK_DATA
       kssif0010-1278    [002] ..... 268046.324315: i2c_write: i2c-0 #0 a=010 f=0000 l=1 [09]
       kssif0010-1278    [002] ..... 268046.324316: i2c_read: i2c-0 #1 a=010 f=0601 l=1
       kssif0010-1278    [002] ..... 268046.325133: i2c_reply: i2c-0 #1 a=010 f=0201 l=33 [20-01-**redacted**]
       kssif0010-1278    [002] ..... 268046.325135: i2c_result: i2c-0 n=2 ret=2
       kssif0010-1278    [002] ..... 268046.325138: smbus_reply: i2c-0 a=010 f=0000 c=9 BLOCK_DATA l=33 [20-01-**redacted**]
       kssif0010-1278    [002] ..... 268046.325139: smbus_result: i2c-0 a=010 f=0000 c=9 BLOCK_DATA rd res=0

The observed behavior within Linux is the IPMI SSIF driver receives the "start" packet and a single "middle" packet then it fails with an "out-of-sequence" error message.