IPMI Restriction Mode

[Vernon Mauery]

On 04-May-2022 10:27 PM, Kumar Thangavel wrote:
>On Wed, May 4, 2022 at 4:34 AM Vernon Mauery <vernon.mauery at linux.intel.com>
>wrote:
>
>> On 03-May-2022 07:46 PM, Kumar Thangavel wrote:
>> >Hi Vernon,
>> >
>> >     We may need to write our own custom filter for other channels as you
>> >suggested.
>> >     While implementing this, we need some clarifications.
>> >
>> >     1. How can we map channel Id's with settingsd restriction mode
>> >dbus-objects ?
>>
>> Set up a restriction mode object for each channel? This is really up to
>> your implementation.
>>
>
>    Ack.
>
>>
>> >     2. The Ipmb channel has multiple devices in our system, How can we
>> >handle and apply this multiple Ipmb interfaces with
>> >settingsd restriction mode dbus-objects ?
>> >
>> >     Please refer below link for multiple Ipmb channels for our system.
>> >
>>
>> When ipmb channel commands come in, there is also rqSA set in the
>> ipmi::Context. This should be unique per device. Will this work for you?
>>
>>     That also works. If we use rqSA, again we need to map this rqSA value
>with phosphor-settingsd restriction mode dbus-objects name (
>/xyz/openbmc_project/control/*host1*/restriction_mode) ?
>
>Alternate logic we just think of
>1. Using "hostIdx'' in ipmi::Contextwhich is unique(0, 1, 2 to N) for each
>devices. we can map this with phosphor-settingsd restriction mode
>dbus-objects name ?  We need to maintain order (0, 1, 2 to N-1) for hosts
>and N for debug cards in all configs.
>2. Can we read i*pmb-channels.json* entry in ipmid with name field as
>"host1", "host2", "host3" "host4" and "debug_card" which should match the
>settingsd dbus-object names. ? So that we can map the name field with
>settings objects easily.
>
>  Example :
>  Ipmb-channels.json entry :
>
>{ "name" : "*host1*"
>"type": "ipmb",
>"slave-path": "/dev/ipmb-1",
>"bmc-addr": 32,
>"remote-addr": 64,
>"devIndex": 0
>},
>{ "name" : "*host2*"
>"type": "ipmb",
>"slave-path": "/dev/ipmb-3",
>"bmc-addr": 32,
>"remote-addr": 64,
>"devIndex": 2
>},
>
>{ "name" : "*hostN*"
>"type": "ipmb",
>"slave-path": "/dev/ipmb-7",
>"bmc-addr": 32,
>"remote-addr": 64,
>"devIndex": N
>},
>{ "name" : "*debug_card*"
>"type": "ipmb",
>"slave-path": "/dev/ipmb-13",
>"bmc-addr": 32,
>"remote-addr": 64,
>"devIndex": 4
>}
>]
>
>  Settingsd restriction mode objects :
>
>  /xyz/openbmc_project/control/*debug_card*/restriction_mode
>  /xyz/openbmc_project/control/*host1*/restriction_mode
>  /xyz/openbmc_project/control/*host2*/restriction_mode
>  /xyz/openbmc_project/control/*host3*/restriction_mode
>  /xyz/openbmc_project/control/*host3*/restriction_mode
>
>  Could you please provide your thoughts on this ?

I think you can do all of this in your filter code. You can really do 
just about anything in there. You can have a setup function that gets 
called when the provider library is loaded and read the file and set up 
your map. Then when an IPMI function is called you can consult your map 
and filter however you want.

Just be aware that your filter code will run on *every* IPMI call, so do 
your best to make it streamlined or it will impact performance.

--Vernon