All of lore.kernel.org
 help / color / mirror / Atom feed
From: tomjose <tomjose@linux.vnet.ibm.com>
To: Patrick Williams <patrick@stwcx.xyz>,
	Brendan Higgins <brendanhiggins@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Discussion on IPMI provider libraries
Date: Wed, 16 Nov 2016 12:30:59 +0530	[thread overview]
Message-ID: <582C042B.6080302@linux.vnet.ibm.com> (raw)
In-Reply-To: <20161115105807.GJ15757@heinlein.lan>



On Tuesday 15 November 2016 04:28 PM, Patrick Williams wrote:
> On Mon, Nov 14, 2016 at 03:59:08PM -0800, Brendan Higgins wrote:
>>> The privilege provided by each command is a registration parameter and it
>>> is consumed only by net-ipmid.
>>
>> That's fine, but in that case it should not go in the callback; it should
>> be maintained and enforced by net-ipmid when it looks up a handler.
> Neither net-ipmid nor host-ipmid intrinsically know all of the IPMI
> commands that will or may be registered.  This is especially true for
> OEM commands where the privilege level is determined by the command.
Agree.
>
> Are the privilege levels defined by the IPMI spec?  If so, I don't see
> anything incorrect about each provider having it.  If not, it is
> something that we have defined at build time, correct?  Would it be
> acceptable to have multiple symlink locations for net-ipmid providers?
> ie. /usr/lib/phosphor-net-ipmid/user/ ,
> /usr/lib/phosphor-net-ipmid/admin/ , etc.  I suspect we would need to
> break libraries up more because currently a single library provides
> commands at different privilege levels.
>
My earlier mail got stripped off when Brendan replied which had details 
about the privilege levels.

The Privilege levels are defined by the IPMI specification. Table G - 
Command Number Assignments and Privilege Levels in the IPMI 
specification gives more details on this.

Every command has a privilege level assigned to the command( Admin, 
User, Operator or Callback) or the command is system interface only.

The plan is to break down the system interface commands into a separate 
library.  The apphandler library in phospor-host-ipmid had support for 
Get Message Flags,
Set BMC Global Enables and Read Event Message Buffer which are System 
Interface commands only. So that net-ipmid would not load the system 
interface commands.
In a similar way if an OEM command need not be loaded for net-ipmid, 
then no symlink would be provided for that library in 
/usr/lib/phosphor-net-ipmid.

I have pushed a patch for separating system interface commands: 
https://gerrit.openbmc-project.xyz/#/c/1020/

I did not completely understand the rationale behind having multiple 
symlink locations for net-ipmid providers. The phosphor-net-ipmid would 
load the provider libraries
at starting and net-ipmid would allow multiple sessions with different 
privilege levels. There is a 'Set Session Privilege Level' command which 
would change the privilege level to a
higher( based on the maximum privilege supported for the user) or lower 
privilege level.

So the suggestion for multiple symlink  locations for net-ipmid 
providers(net-ipmid/user.. net-ipmid/admin) is a way for net-ipmid to 
figure out the privilege level of the command
instead of a registration parameter(privilege level) in the callback 
handler?

      reply	other threads:[~2016-11-16  7:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-07 13:43 Discussion on IPMI provider libraries tomjose
2016-11-07 20:25 ` Brendan Higgins
2016-11-08 10:09   ` tomjose
2016-11-14 23:59     ` Brendan Higgins
2016-11-15 10:58       ` Patrick Williams
2016-11-16  7:00         ` tomjose [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=582C042B.6080302@linux.vnet.ibm.com \
    --to=tomjose@linux.vnet.ibm.com \
    --cc=brendanhiggins@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.