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 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