New repo request: phosphor-ipmi-blobs-binarystore

[Brad Bishop]

> On Dec 17, 2018, at 6:16 PM, Kun Yi <kunyi at 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 at 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 at google.com), and Patrick Venture (venture at 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