New repo request: phosphor-ipmi-blobs-skm

New repo request: phosphor-ipmi-blobs-skm

[Kun Yi]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Hi Brad,

May I request a new repository: phosphor-ipmi-blobs-skm?

It is a phosphor-ipmi-blobs[1] based handler that supports simple binary
data read/write/enumerate operations from the host to a storage only
visible to BMC. Google uses it for storing Storage Key Management (SKM)
specific binary data, and it may probably belong to the openBMC
customizations that Google want to publish and permit others to use.

Currently the storage format is skm specific, but it could be expanded to
support other use cases, thus the "phosphor" naming. If you feel that it is
still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well.
We can always rename this later if the use cases expand. =)

Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick
Venture (venture@google.com) as maintainers. Thanks!

[1] https://github.com/openbmc/phosphor-ipmi-blobs
-- 
Regards,
Kun

[-- Attachment #2: Type: text/html, Size: 1315 bytes --]

Re: New repo request: phosphor-ipmi-blobs-skm

[Ed Tanous]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

Can you go into a little more details on what this repository would do? 
A quick google of "storage key management" didn't really turn up much in
terms of specifics.  Is there a spec or design doc you could point us at?

Some initial questions I have (assuming this repo relates to key management)

1. How would this repository relate to phosphor-certificate-manager? 
Reimplementation of the same interface?  Different?  What are the major
differences that would warrant not simply putting the implementation
there?  Some of my confusion here is that phosphor-certificate-manager
has an implementation that can store certificates and private keys, and
has gone through many rounds of review on the interfaces.  I'm worried
that another key manager would simply be duplicating functionality that
already exists (although I hope not).

2. What interfaces and workflows would this implementation support? 
What does this implementation let us do that we can't do already?

3. When you say the storage format is SKM specific, what does that mean?

-Ed

On 12/6/18 10:19 AM, Kun Yi wrote:
> Hi Brad,
>
> May I request a new repository: phosphor-ipmi-blobs-skm?
>
> It is a phosphor-ipmi-blobs[1] based handler that supports simple
> binary data read/write/enumerate operations from the host to a storage
> only visible to BMC. Google uses it for storing Storage Key Management
> (SKM) specific binary data, and it may probably belong to the openBMC
> customizations that Google want to publish and permit others to use.
>
> Currently the storage format is skm specific, but it could be expanded
> to support other use cases, thus the "phosphor" naming. If you feel
> that it is still Google-specific, then "google-ipmi-blobs-skm" is
> acceptable as well. We can always rename this later if the use cases
> expand. =)
>
> Please add myself, Benjamin Fair (benjaminfair@google.com
> <mailto:benjaminfair@google.com>), and Patrick Venture
> (venture@google.com <mailto:venture@google.com>) as maintainers. Thanks!
>
> [1] https://github.com/openbmc/phosphor-ipmi-blobs
> -- 
> Regards,
> Kun

[-- Attachment #2: Type: text/html, Size: 3664 bytes --]

Re: New repo request: phosphor-ipmi-blobs-skm

[Kun Yi]

Great questions and sorry for not being clear in the first email.
Responses inline.

On Thu, Dec 6, 2018 at 10:30 AM Ed Tanous <ed.tanous@intel.com> wrote:
>
> Can you go into a little more details on what this repository would do?  A quick google of "storage key management" didn't really turn up much in terms of specifics.  Is there a spec or design doc you could point us at?

After some internal discussions we feel the design could be more
generalized. It is better described as a BMC binary blob store backend
with simple read/write interface through IPMI blobs. The
characteristics of this backend are:
1. Support for read/write of short binary data onto BMC persistent
storage, or any storage device that BMC has access to
2. The binary data are stored at compile-time known offsets and can be
accessed offline

It is *NOT* meant for storing keys despite my original email
mentioning a "storage key management system". Our internal use-case is
basically placing some strings onto BMC persistent storage and have
them accessible online(through IPMI) and/or offline. Again, due to the
fact that multiple entities have access to the data, no keys/secrets
should be stored using this backend.

I could definitely send a design to the docs repo for anyone
interested to comment on.

>
> Some initial questions I have (assuming this repo relates to key management)
>
> 1. How would this repository relate to phosphor-certificate-manager?  Reimplementation of the same interface?  Different?  What are the major differences that would warrant not simply putting the implementation there?  Some of my confusion here is that phosphor-certificate-manager has an implementation that can store certificates and private keys, and has gone through many rounds of review on the interfaces.  I'm worried that another key manager would simply be duplicating functionality that already exists (although I hope not).
>
> 2. What interfaces and workflows would this implementation support?  What does this implementation let us do that we can't do already?

I hope my response above clarifies 1) and 2): it is not similar to
existing keystore infrastructure since they serve different purposes.

>
> 3. When you say the storage format is SKM specific, what does that mean?

My original design involves some specific metadata fields, but those
are overly arbitrary and can be replaced by a generic approach.

>
> -Ed
>
> On 12/6/18 10:19 AM, Kun Yi wrote:
>
> Hi Brad,
>
> May I request a new repository: phosphor-ipmi-blobs-skm?
>
> It is a phosphor-ipmi-blobs[1] based handler that supports simple binary data read/write/enumerate operations from the host to a storage only visible to BMC. Google uses it for storing Storage Key Management (SKM) specific binary data, and it may probably belong to the openBMC customizations that Google want to publish and permit others to use.
>
> Currently the storage format is skm specific, but it could be expanded to support other use cases, thus the "phosphor" naming. If you feel that it is still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well. We can always rename this later if the use cases expand. =)
>
> Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick Venture (venture@google.com) as maintainers. Thanks!
>
> [1] https://github.com/openbmc/phosphor-ipmi-blobs
> --
> Regards,
> Kun



-- 
Regards,
Kun

Re: New repo request: phosphor-ipmi-blobs-skm

[Kun Yi]

On Fri, Dec 7, 2018 at 10:35 AM Kun Yi <kunyi@google.com> wrote:
>
> Great questions and sorry for not being clear in the first email.
> Responses inline.
>
> On Thu, Dec 6, 2018 at 10:30 AM Ed Tanous <ed.tanous@intel.com> wrote:
> >
> > Can you go into a little more details on what this repository would do?  A quick google of "storage key management" didn't really turn up much in terms of specifics.  Is there a spec or design doc you could point us at?
>
> After some internal discussions we feel the design could be more
> generalized. It is better described as a BMC binary blob store backend
> with simple read/write interface through IPMI blobs. The
> characteristics of this backend are:
> 1. Support for read/write of short binary data onto BMC persistent
> storage, or any storage device that BMC has access to
> 2. The binary data are stored at compile-time known offsets and can be
> accessed offline
>
> It is *NOT* meant for storing keys despite my original email
> mentioning a "storage key management system". Our internal use-case is
> basically placing some strings onto BMC persistent storage and have
> them accessible online(through IPMI) and/or offline. Again, due to the
> fact that multiple entities have access to the data, no keys/secrets
> should be stored using this backend.
>
> I could definitely send a design to the docs repo for anyone
> interested to comment on.
>
> >
> > Some initial questions I have (assuming this repo relates to key management)
> >
> > 1. How would this repository relate to phosphor-certificate-manager?  Reimplementation of the same interface?  Different?  What are the major differences that would warrant not simply putting the implementation there?  Some of my confusion here is that phosphor-certificate-manager has an implementation that can store certificates and private keys, and has gone through many rounds of review on the interfaces.  I'm worried that another key manager would simply be duplicating functionality that already exists (although I hope not).
> >
> > 2. What interfaces and workflows would this implementation support?  What does this implementation let us do that we can't do already?
>
> I hope my response above clarifies 1) and 2): it is not similar to
> existing keystore infrastructure since they serve different purposes.
>
> >
> > 3. When you say the storage format is SKM specific, what does that mean?
>
> My original design involves some specific metadata fields, but those
> are overly arbitrary and can be replaced by a generic approach.
>
> >
> > -Ed
> >
> > On 12/6/18 10:19 AM, Kun Yi wrote:
> >
> > Hi Brad,
> >
> > May I request a new repository: phosphor-ipmi-blobs-skm?
> >
> > It is a phosphor-ipmi-blobs[1] based handler that supports simple binary data read/write/enumerate operations from the host to a storage only visible to BMC. Google uses it for storing Storage Key Management (SKM) specific binary data, and it may probably belong to the openBMC customizations that Google want to publish and permit others to use.
> >
> > Currently the storage format is skm specific, but it could be expanded to support other use cases, thus the "phosphor" naming. If you feel that it is still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well. We can always rename this later if the use cases expand. =)
> >
> > Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick Venture (venture@google.com) as maintainers. Thanks!
> >
> > [1] https://github.com/openbmc/phosphor-ipmi-blobs
> > --
> > Regards,
> > Kun
>
>
>
> --
> Regards,
> Kun

I have uploaded the design doc at
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/16584. Currently
added Joseph, Brad, Patrick and Benjamin for review. If you are
interested please add your self as a reviewer. Thanks!

-- 
Regards,
Kun

Re: New repo request: phosphor-ipmi-blobs-binarystore

[Kun Yi]

Hi Ed,

I hope my last email and the design doc address your questions? =)

Hi Brad,

Since the handler is made more general, the name should not contain
SKM anymore. Please use 'phosphor-ipmi-blobs-binarystore'.
Changed email subject for clarity.

> > On Thu, Dec 6, 2018 at 10:30 AM Ed Tanous <ed.tanous@intel.com> wrote:
> > >
> > > Can you go into a little more details on what this repository would do?  A quick google of "storage key management" didn't really turn up much in terms of specifics.  Is there a spec or design doc you could point us at?
> >
> > After some internal discussions we feel the design could be more
> > generalized. It is better described as a BMC binary blob store backend
> > with simple read/write interface through IPMI blobs. The
> > characteristics of this backend are:
> > 1. Support for read/write of short binary data onto BMC persistent
> > storage, or any storage device that BMC has access to
> > 2. The binary data are stored at compile-time known offsets and can be
> > accessed offline
> >
> > It is *NOT* meant for storing keys despite my original email
> > mentioning a "storage key management system". Our internal use-case is
> > basically placing some strings onto BMC persistent storage and have
> > them accessible online(through IPMI) and/or offline. Again, due to the
> > fact that multiple entities have access to the data, no keys/secrets
> > should be stored using this backend.
> >
> > I could definitely send a design to the docs repo for anyone
> > interested to comment on.
> >
> > >
> > > Some initial questions I have (assuming this repo relates to key management)
> > >
> > > 1. How would this repository relate to phosphor-certificate-manager?  Reimplementation of the same interface?  Different?  What are the major differences that would warrant not simply putting the implementation there?  Some of my confusion here is that phosphor-certificate-manager has an implementation that can store certificates and private keys, and has gone through many rounds of review on the interfaces.  I'm worried that another key manager would simply be duplicating functionality that already exists (although I hope not).
> > >
> > > 2. What interfaces and workflows would this implementation support?  What does this implementation let us do that we can't do already?
> >
> > I hope my response above clarifies 1) and 2): it is not similar to
> > existing keystore infrastructure since they serve different purposes.
> >
> > >
> > > 3. When you say the storage format is SKM specific, what does that mean?
> >
> > My original design involves some specific metadata fields, but those
> > are overly arbitrary and can be replaced by a generic approach.
> >
> > >
> > > -Ed
> > >
> > > On 12/6/18 10:19 AM, Kun Yi wrote:
> > >
> > > Hi Brad,
> > >
> > > May I request a new repository: phosphor-ipmi-blobs-skm?
> > >
> > > It is a phosphor-ipmi-blobs[1] based handler that supports simple binary data read/write/enumerate operations from the host to a storage only visible to BMC. Google uses it for storing Storage Key Management (SKM) specific binary data, and it may probably belong to the openBMC customizations that Google want to publish and permit others to use.
> > >
> > > Currently the storage format is skm specific, but it could be expanded to support other use cases, thus the "phosphor" naming. If you feel that it is still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well. We can always rename this later if the use cases expand. =)
> > >
> > > Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick Venture (venture@google.com) as maintainers. Thanks!
> > >
> > > [1] https://github.com/openbmc/phosphor-ipmi-blobs
> > > --
> > > Regards,
> > > Kun
> >
> >
> >
> > --
> > Regards,
> > Kun
>
> I have uploaded the design doc at
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/16584. Currently
> added Joseph, Brad, Patrick and Benjamin for review. If you are
> interested please add your self as a reviewer. Thanks!
>
> --
> Regards,
> Kun



-- 
Regards,
Kun

Re: New repo request: phosphor-ipmi-blobs-binarystore

[Brad Bishop]

> On Dec 17, 2018, at 6:16 PM, Kun Yi <kunyi@google.com> wrote:
> 
> Hi Ed,
> 
> I hope my last email and the design doc address your questions? =)
> 
> Hi Brad,
> 
> Since the handler is made more general, the name should not contain
> SKM anymore. Please use 'phosphor-ipmi-blobs-binarystore’.

Hi Kun

Just wanted to verify quick before I do it that you still want a
phosphor-ipmi-blobs-binarystore repository?

thx - brad

> Changed email subject for clarity.
> 
>>> On Thu, Dec 6, 2018 at 10:30 AM Ed Tanous <ed.tanous@intel.com> wrote:
>>>> 
>>>> Can you go into a little more details on what this repository would do?  A quick google of "storage key management" didn't really turn up much in terms of specifics.  Is there a spec or design doc you could point us at?
>>> 
>>> After some internal discussions we feel the design could be more
>>> generalized. It is better described as a BMC binary blob store backend
>>> with simple read/write interface through IPMI blobs. The
>>> characteristics of this backend are:
>>> 1. Support for read/write of short binary data onto BMC persistent
>>> storage, or any storage device that BMC has access to
>>> 2. The binary data are stored at compile-time known offsets and can be
>>> accessed offline
>>> 
>>> It is *NOT* meant for storing keys despite my original email
>>> mentioning a "storage key management system". Our internal use-case is
>>> basically placing some strings onto BMC persistent storage and have
>>> them accessible online(through IPMI) and/or offline. Again, due to the
>>> fact that multiple entities have access to the data, no keys/secrets
>>> should be stored using this backend.
>>> 
>>> I could definitely send a design to the docs repo for anyone
>>> interested to comment on.
>>> 
>>>> 
>>>> Some initial questions I have (assuming this repo relates to key management)
>>>> 
>>>> 1. How would this repository relate to phosphor-certificate-manager?  Reimplementation of the same interface?  Different?  What are the major differences that would warrant not simply putting the implementation there?  Some of my confusion here is that phosphor-certificate-manager has an implementation that can store certificates and private keys, and has gone through many rounds of review on the interfaces.  I'm worried that another key manager would simply be duplicating functionality that already exists (although I hope not).
>>>> 
>>>> 2. What interfaces and workflows would this implementation support?  What does this implementation let us do that we can't do already?
>>> 
>>> I hope my response above clarifies 1) and 2): it is not similar to
>>> existing keystore infrastructure since they serve different purposes.
>>> 
>>>> 
>>>> 3. When you say the storage format is SKM specific, what does that mean?
>>> 
>>> My original design involves some specific metadata fields, but those
>>> are overly arbitrary and can be replaced by a generic approach.
>>> 
>>>> 
>>>> -Ed
>>>> 
>>>> On 12/6/18 10:19 AM, Kun Yi wrote:
>>>> 
>>>> Hi Brad,
>>>> 
>>>> May I request a new repository: phosphor-ipmi-blobs-skm?
>>>> 
>>>> It is a phosphor-ipmi-blobs[1] based handler that supports simple binary data read/write/enumerate operations from the host to a storage only visible to BMC. Google uses it for storing Storage Key Management (SKM) specific binary data, and it may probably belong to the openBMC customizations that Google want to publish and permit others to use.
>>>> 
>>>> Currently the storage format is skm specific, but it could be expanded to support other use cases, thus the "phosphor" naming. If you feel that it is still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well. We can always rename this later if the use cases expand. =)
>>>> 
>>>> Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick Venture (venture@google.com) as maintainers. Thanks!
>>>> 
>>>> [1] https://github.com/openbmc/phosphor-ipmi-blobs
>>>> --
>>>> Regards,
>>>> Kun
>>> 
>>> 
>>> 
>>> --
>>> Regards,
>>> Kun
>> 
>> I have uploaded the design doc at
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/16584. Currently
>> added Joseph, Brad, Patrick and Benjamin for review. If you are
>> interested please add your self as a reviewer. Thanks!
>> 
>> --
>> Regards,
>> Kun
> 
> 
> 
> -- 
> Regards,
> Kun

Re: New repo request: phosphor-ipmi-blobs-binarystore

[Kun Yi]

On Mon, Jan 14, 2019 at 7:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
>
>
> > On Dec 17, 2018, at 6:16 PM, Kun Yi <kunyi@google.com> wrote:
> >
> > Hi Ed,
> >
> > I hope my last email and the design doc address your questions? =)
> >
> > Hi Brad,
> >
> > Since the handler is made more general, the name should not contain
> > SKM anymore. Please use 'phosphor-ipmi-blobs-binarystore’.
>
> Hi Kun
>
> Just wanted to verify quick before I do it that you still want a
> phosphor-ipmi-blobs-binarystore repository?
>
> thx - brad

Yes, we still intend to make the code available for upstream. Thanks!

>
> > Changed email subject for clarity.
> >
> >>> On Thu, Dec 6, 2018 at 10:30 AM Ed Tanous <ed.tanous@intel.com> wrote:
> >>>>
> >>>> Can you go into a little more details on what this repository would do?  A quick google of "storage key management" didn't really turn up much in terms of specifics.  Is there a spec or design doc you could point us at?
> >>>
> >>> After some internal discussions we feel the design could be more
> >>> generalized. It is better described as a BMC binary blob store backend
> >>> with simple read/write interface through IPMI blobs. The
> >>> characteristics of this backend are:
> >>> 1. Support for read/write of short binary data onto BMC persistent
> >>> storage, or any storage device that BMC has access to
> >>> 2. The binary data are stored at compile-time known offsets and can be
> >>> accessed offline
> >>>
> >>> It is *NOT* meant for storing keys despite my original email
> >>> mentioning a "storage key management system". Our internal use-case is
> >>> basically placing some strings onto BMC persistent storage and have
> >>> them accessible online(through IPMI) and/or offline. Again, due to the
> >>> fact that multiple entities have access to the data, no keys/secrets
> >>> should be stored using this backend.
> >>>
> >>> I could definitely send a design to the docs repo for anyone
> >>> interested to comment on.
> >>>
> >>>>
> >>>> Some initial questions I have (assuming this repo relates to key management)
> >>>>
> >>>> 1. How would this repository relate to phosphor-certificate-manager?  Reimplementation of the same interface?  Different?  What are the major differences that would warrant not simply putting the implementation there?  Some of my confusion here is that phosphor-certificate-manager has an implementation that can store certificates and private keys, and has gone through many rounds of review on the interfaces.  I'm worried that another key manager would simply be duplicating functionality that already exists (although I hope not).
> >>>>
> >>>> 2. What interfaces and workflows would this implementation support?  What does this implementation let us do that we can't do already?
> >>>
> >>> I hope my response above clarifies 1) and 2): it is not similar to
> >>> existing keystore infrastructure since they serve different purposes.
> >>>
> >>>>
> >>>> 3. When you say the storage format is SKM specific, what does that mean?
> >>>
> >>> My original design involves some specific metadata fields, but those
> >>> are overly arbitrary and can be replaced by a generic approach.
> >>>
> >>>>
> >>>> -Ed
> >>>>
> >>>> On 12/6/18 10:19 AM, Kun Yi wrote:
> >>>>
> >>>> Hi Brad,
> >>>>
> >>>> May I request a new repository: phosphor-ipmi-blobs-skm?
> >>>>
> >>>> It is a phosphor-ipmi-blobs[1] based handler that supports simple binary data read/write/enumerate operations from the host to a storage only visible to BMC. Google uses it for storing Storage Key Management (SKM) specific binary data, and it may probably belong to the openBMC customizations that Google want to publish and permit others to use.
> >>>>
> >>>> Currently the storage format is skm specific, but it could be expanded to support other use cases, thus the "phosphor" naming. If you feel that it is still Google-specific, then "google-ipmi-blobs-skm" is acceptable as well. We can always rename this later if the use cases expand. =)
> >>>>
> >>>> Please add myself, Benjamin Fair (benjaminfair@google.com), and Patrick Venture (venture@google.com) as maintainers. Thanks!
> >>>>
> >>>> [1] https://github.com/openbmc/phosphor-ipmi-blobs
> >>>> --
> >>>> Regards,
> >>>> Kun
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Kun
> >>
> >> I have uploaded the design doc at
> >> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/16584. Currently
> >> added Joseph, Brad, Patrick and Benjamin for review. If you are
> >> interested please add your self as a reviewer. Thanks!
> >>
> >> --
> >> Regards,
> >> Kun
> >
> >
> >
> > --
> > Regards,
> > Kun



-- 
Regards,
Kun

Re: New repo request: phosphor-ipmi-blobs-binarystore

[Brad Bishop]

> On Jan 14, 2019, at 2:09 PM, Kun Yi <kunyi@google.com> wrote:
> 
>> On Mon, Jan 14, 2019 at 7:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>> Hi Kun
>> 
>> Just wanted to verify quick before I do it that you still want a
>> phosphor-ipmi-blobs-binarystore repository?
>> 
>> thx - brad
> 
> Yes, we still intend to make the code available for upstream. Thanks!

done!