Mapping IPMI boot device selector to D-Bbus properties

Mapping IPMI boot device selector to D-Bbus properties

[Deepak Kodihalli]

Hi,

We recently discovered an issue in the way the IPMI boot device selector 
(represented by a nibble in the boot flags) is mapped to the D-Bus model.

In the IPMI spec the boot device selector has options for both "boot 
source" (default/disk/crdom/network) and "boot mode" 
(default/bios/safe/diag). Since this isn't a bit-filed, you can't 
override for eg both the source and mode at the same time. It's probably 
debatable to say whether such a possibility is desirable or not (for eg 
I may want to set the boot source as network by default, but want to 
boot to safe mode the next boot , and revert back to network for 
subsequent boots without having to set the device again).

There are different D-Bus interfaces depicting the boot mode [1] and 
boot source [2] though. So when the IPMI boot device is changed, the 
ipmid code sets a relevant boot mode or source property. It's possible 
that both can get set when someone for eg sets the device to cdrom and 
then to bios. The issue is how should ipmid respond to a get boot 
options command - there's no way for ipmid to aggregate information from 
both D-Bus properties as in the IPMI spec only one of them can be 
represented. Today ipmid always favors the boot source property if both 
are set [3]. That's not what a user expects though, because the user 
would expect his last override to go through.

The solution I'm proposing is that if a set boot device is mapping to a 
boot source, then reset the boot mode D-Bus property to default, or vice 
versa. This way the ipmid code can determine which property is not at 
the default value. It doesn't break the behavior from an IPMI spec 
perspective because only one can be set at a point of time anyway, and 
we'll consume the latest override to the boot device. Other solutions or 
thoughts?

[1] 
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Boot/Mode.interface.yaml
[2] 
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Boot/Source.interface.yaml
[3] 
https://github.com/openbmc/phosphor-host-ipmid/blob/master/chassishandler.cpp#L1257

Thanks,
Deepak

Re: Mapping IPMI boot device selector to D-Bbus properties

[Stewart Smith]

Deepak Kodihalli <dkodihal@linux.vnet.ibm.com> writes:
> We recently discovered an issue in the way the IPMI boot device selector 
> (represented by a nibble in the boot flags) is mapped to the D-Bus
> model.

for anyone playing at home, this was caught by op-test:

git clone https://github.com/open-power/op-test-framework.git
cd op-test-framework
./op-test <insert auth details here> --run testcases.OpTestInbandIPMI.SkirootFullInbandIPMI.test_chassis_bootdev

and this test does pass on other BMC IPMI implementations (such as AMI).

Although the exact failure was only really an accident of the test
rather than on purpose.

A happy accident at least as it means we found a bug :)

> In the IPMI spec the boot device selector has options for both "boot 
> source" (default/disk/crdom/network) and "boot mode" 
> (default/bios/safe/diag). Since this isn't a bit-filed, you can't 
> override for eg both the source and mode at the same time. It's probably 
> debatable to say whether such a possibility is desirable or not (for eg 
> I may want to set the boot source as network by default, but want to 
> boot to safe mode the next boot , and revert back to network for 
> subsequent boots without having to set the device again).
>
> There are different D-Bus interfaces depicting the boot mode [1] and 
> boot source [2] though. So when the IPMI boot device is changed, the 
> ipmid code sets a relevant boot mode or source property. It's possible 
> that both can get set when someone for eg sets the device to cdrom and 
> then to bios. The issue is how should ipmid respond to a get boot 
> options command - there's no way for ipmid to aggregate information from 
> both D-Bus properties as in the IPMI spec only one of them can be 
> represented. Today ipmid always favors the boot source property if both 
> are set [3]. That's not what a user expects though, because the user 
> would expect his last override to go through.
>
> The solution I'm proposing is that if a set boot device is mapping to a 
> boot source, then reset the boot mode D-Bus property to default, or vice 
> versa. This way the ipmid code can determine which property is not at 
> the default value. It doesn't break the behavior from an IPMI spec 
> perspective because only one can be set at a point of time anyway, and 
> we'll consume the latest override to the boot device. Other solutions or 
> thoughts?

Do we know the behaviour of other IPMI implementations? My *guess* would
be is that they only track one bit of information and the boot mode will
override the previous request for boot source.

Perhaps the correct behaviour is to reset the temporary boot source when
boot mode is set and vice versa? It kind-of seems like that's the intent
from reading the IPMI spec, but I'd appreciate input and being proven
wrong :)

-- 
Stewart Smith
OPAL Architect, IBM.