Discussion on openbmc issue #430
*Design and Implement Framework for IPMI backend*
------------------------------------------------------------------------------
The purpose of this is to come up with a mechanism to share providers between the host-ipmid and the rmcp-ipmid. Also, update existing providers and host-ipmid to fit this framework. Demo of this story should be to use an existing host-ipmid provider via the rmcp path.
*Registering Callback Routines:-*
-----------------------------------------------
1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
2) Scan for libraries that end with .so
3) Do a dlopen that would register the handlers for the callback routines. The data that is currently registered for each command: Net Function, Command and Functor.
*Additional Metadata needed per command:-*
-----------------------------------------------------------------
*SessionLess Commands :-
*-------------------------------------*
*
This would mention whether the command can be executed without a session. For example Get Channel Capabilities can be executed without a session.
*Minimum Privilege Required to Execute the command :-
*---------------------------------------------------------------------------------*
*This field would mention the minimum privilege of the session required to execute the command. Before executing any command on a session, the command would be executed only if the command privilege level is less than or equal to session privilege level. The privilege levels are Administrator, Operator, User and Callback and OEM
*Firmware Firewalling :-
*--------------------------------*
**Channel Restriction :-
*------------------------------*
*The channel restriction can be applied if certain command needs to be restricted on System Interface or LAN Interface.
The Get NetFn/ Command support can be used to get a list of commands that are supported on a given channel. Implementation of these commands is not in the scope of this story.
*Command Firewalling:-
*--------------------------------*
*Configuration of Firmware Firewall capabilities is supported by commands that allow software to enable/disable individual commands. The Firmware Firewall capability does not affect the operation of user and channel privileges.
That is, if a command requires Admin privilege level to be executed, it will still require Admin privilege if enabled by Firmware Firewall.
The different values that are supported for this field is:
a) Command is supported by default(can be configured(enabled or disabled)
b) Supported and cannot be configured( enable/disable is restricted)
c) Disabled by default but can be configured.
The firmware firewalling commands once supported would support the above operations.
Regards,
Tom
Tom,
Thanks for sending this out to the broader community.
Few comments below...
Quoted 3 lines · tomjose
*Registering Callback Routines:-*
-----------------------------------------------
1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)
I would prefer we have a new directory '/usr/lib/phosphor-net-ipmid' for the RMCP libraries. We can create symlinks between the two repos as appropriate.
The reason for this is two-fold:
1) I suspect there will be some of the OEM commands that we will want to expose in-band only.
2) There are commands that may want similarly excluded from the in-band path due to security concerns (even though we have the white-list support).
We might want to have a '/usr/lib/ipmid-providers' as the default install location for all providers and then symlink into both phosphor-net and phosphor-host as appropriate.
Quoted 1 line
2) Scan for libraries that end with .so
Keep in mind you'll need to deal with versioned .so's as well. We had to add that support to host-ipmid recently.
Quoted 3 lines
3) Do a dlopen that would register the handlers for the callback routines. The data that is currently registered for each command: Net Function, Command and Functor.
There are a few providers that register for dbus callbacks so they can monitor signals. We'll need to discuss a little more I think on what the expectation is here. Maybe the way we are doing dbus callbacks isn't appropriate to begin with, or maybe the callbacks are for host alerts and not needed in the network path?
Quoted 6 lines
*SessionLess Commands :-
*-------------------------------------*
*
This would mention whether the command can be executed without a session. For example
Get Channel Capabilities can be executed without a session.
How do we identify session-less commands? Should this be an enhancement to the registration API?
Quoted 10 lines
*Minimum Privilege Required to Execute the command :-
*---------------------------------------------------------------------------------**This field would mention the minimum privilege of the session required to execute the
command. Before executing any command on a session, the command would be executed
only if the command privilege level is less than or equal to session privilege level.
The privilege levels are Administrator, Operator, User and Callback and OEM
Are these privilege levels something intrinsic in IPMI or something you came up with?
We plan to integrate the ipmi server into the same BMC user list as the REST interface. I think we need to identify these roles and then allow unix-group membership to determine which commands can be ran.
We have a feature to be implemented for the REST interface to define group membership requirements for dbus / REST calls as well.
How should providers specify these?
Signature · 1 line
Patrick Williams
Thanks Patrick for your feedack. I have mentioned my responses inline.
Quoted 21 lines · Patrick Williams
Tom,
Thanks for sending this out to the broader community.
Few comments below...
Quoted 3 lines · tomjose
*Registering Callback Routines:-*
-----------------------------------------------
1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)I would prefer we have a new directory '
/usr/lib/phosphor-net-ipmid' for the RMCP libraries. We can create symlinks between the two repos as appropriate.The reason for this is two-fold:
1) I suspect there will be some of the OEM commands that we will want to expose in-band only.
2) There are commands that may want similarly excluded from the in-band path due to security concerns (even though we have the white-list support).
Quoted 3 lines
We might want to have a '
/usr/lib/ipmid-providers' as the default install location for all providers and then symlink into both phosphor-net and phosphor-host as appropriate.
In the proposal, i had mentioned there is a provision to add channel restrictions to each command. There are 3 variants available: execute on any channel, execute in-band only and execute on lan only. The channel restriction would be evaluated before each command is executed.
I hope this would meet the same requirements.
Quoted 4 lines
Quoted 2 lines
2) Scan for libraries that end with .so
Keep in mind you'll need to deal with versioned .so's as well. We had to add that support to host-ipmid recently.
Sure would take this into account while implementing.
Quoted 10 lines
Quoted 4 lines
3) Do a dlopen that would register the handlers for the callback routines. The data that is currently registered for each command: Net Function, Command and Functor.
There are a few providers that register for dbus callbacks so they can monitor signals. We'll need to discuss a little more I think on what the expectation is here. Maybe the way we are doing dbus callbacks isn't appropriate to begin with, or maybe the callbacks are for host alerts and not needed in the network path?
Quoted 8 lines
Quoted 6 lines
*SessionLess Commands :-
*-------------------------------------*
*
This would mention whether the command can be executed without a session. For example
Get Channel Capabilities can be executed without a session.How do we identify session-less commands? Should this be an enhancement to the registration API?
The session less commands are mentioned in the IPMI specification. Examples are Get Channel Authentication Capabilites, Activate Session command etc.
Quoted 14 lines
Quoted 11 lines
*Minimum Privilege Required to Execute the command :-
*---------------------------------------------------------------------------------**This field would mention the minimum privilege of the session required to execute the
command. Before executing any command on a session, the command would be executed
only if the command privilege level is less than or equal to session privilege level.
The privilege levels are Administrator, Operator, User and Callback and OEMAre these privilege levels something intrinsic in IPMI or something you came up with?
Quoted 8 lines
We plan to integrate the ipmi server into the same BMC user list as the REST interface. I think we need to identify these roles and then allow unix-group membership to determine which commands can be ran.
We have a feature to be implemented for the REST interface to define group membership requirements for dbus / REST calls as well.
How should providers specify these?
The privilege levels attributed to each command is mentioned in the specification. It is mentioned in the specification Table G-1,(Command Number Assignments and Privilege Levels). The providers should provide these as registration parameters when the callbacks are registered.
Quoted 1 line
Quoted 28 lines · tomjose
Thanks Patrick for your feedack. I have mentioned my responses inline.
Quoted 21 lines · Patrick Williams
Tom,
Thanks for sending this out to the broader community.
Few comments below...
Quoted 3 lines · tomjose
*Registering Callback Routines:-*
-----------------------------------------------
1) Open the IPMI library path(/usr/lib/phosphor-host-ipmid)I would prefer we have a new directory '
/usr/lib/phosphor-net-ipmid' for the RMCP libraries. We can create symlinks between the two repos as appropriate.The reason for this is two-fold:
1) I suspect there will be some of the OEM commands that we will want to expose in-band only.
2) There are commands that may want similarly excluded from the in-band path due to security concerns (even though we have the white-list support).Quoted 3 lines
We might want to have a '
/usr/lib/ipmid-providers' as the default install location for all providers and then symlink into both phosphor-net and phosphor-host as appropriate.
Quoted 6 lines
In the proposal, i had mentioned there is a provision to add channel restrictions to each command.
There are 3 variants available: execute on any channel, execute in-band only and execute on lan only.
The channel restriction would be evaluated before each command is executed. I hope this would meet the same requirements.
I would rather not codify that in the provider itself. By using symlinks we allow the system engineers to specify different behavior for their system without having to modify code. ie. through .bbappend changes to the recipe.
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
*SessionLess Commands :-
*-------------------------------------*
*
This would mention whether the command can be executed without a session. For example
Get Channel Capabilities can be executed without a session.How do we identify session-less commands? Should this be an enhancement to the registration API?
The session less commands are mentioned in the IPMI specification. Examples are Get Channel Authentication Capabilites, Activate Session command etc.
I meant how are they identified by the provider? You could want to implement an OEM command that is session-less. We need that identified by the provider when they do registration?
Quoted 7 lines
The privilege levels attributed to each command is mentioned in the specification.
It is mentioned in the specification Table G-1,(Command Number Assignments and
Privilege Levels). The providers should provide these as registration parameters
when the callbacks are registered.
Ok. Those can be default groups. Isn't there also a mechanism to create custom groups with IPMI? Since we plan to map IPMI users back to PAM users, do we also need to map roles back to PAM groups?
Signature · 1 line
Patrick Williams