Request for a new repository to enable Hardware Isolation (Guard)

[Ed Tanous]

On Fri, Jun 25, 2021 at 8:54 AM Ramesh I I1 <rameshi1 at in.ibm.com> wrote:
>
> Hi All,
>
>
>
> Recently a design document [https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/27804] merged to enable the hardware isolation (guard) and it requires a new daemon inside BMC to implement below dbus interfaces.
>
>
>
> DBus Interfaces:
>
> - https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/43532
>
> - https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/43533
>
> - https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-dbus-interfaces/+/44229
>
>
>
> The above dbus interface implementation will be host architecture-specific because of the below reasons.
>
>
>
> - The daemon will create a record (a format used in the OpenPOWER project for isolating hardware) into a partition (which is accessible between BMC and host applications in OpenPOWER based systems) and the daemon will create a dbus entry for the same record.
>
>
>
> - Similarly, the OpenPOWER based host applications will create a record into a partition and the daemon will create a dbus entry for the same record.

So the record storage and ownership will be owned by both the
OpenPOWER host applications and the BMC guard daemon?  In a scenario
where the BMC was managing the given devices, how would that work?
Hypothetically if this were used to implement something like FRB from
the BMC (like other BMC stacks do) how would that work?

>
>
>
> The end goal is, exchanging the isolated hardware details from internal interfaces (dbus entry) to external interfaces (redfish log entry).
>
>
>
> I had two thoughts about the dbus implementation.
>
>
>
> Option1:
>
>
>
> "New generic daemon" with an extension like how phosphor-logging or phosphor-debug-collector or pldm providing a way to add OEM code.
>
>  - Default case nothing will be there, because we (IBM) are not providing any support through standard host interfaces to isolate hardware.
>
>  - The extension will have OEM-specific implementation.
>
>
>
> Option2:
>
> "New OEM daemon" so, implementation will be OEM specific and platform can get from them respective bitbake meta-layer.
>
>

>From my perspective, I would have thought this would be more
distributed;  Each application that wants to implement a "guard"
feature, would expose that through its interfaces, and leave the
implementation details completely to whatever the application itself
wanted to do.  Creating an empty base implementation and expecting
everything that wants to implement this API to extend OEM seems like
it would require a lot of code and a lot of repos.

>
> For Option1, I am wondering about the following scenario.
>
> - If the BMC application (bmcweb) using a generic internal interface (dbus) but, the implementation is OEM specific then, the different system platforms will get a response like "Interface/ObjectPath Not Found" so, the respective redfish URI (which will be used to do create|list) will fail, right?

If this goes in line with other times we've solved this problem,
bmcweb will call the mapper, and ask it "give me all resources of type
CPU".  Then a subsequent call will be made to determine "for this cpu
dbus path, tell me which daemon implements hardware isolation".  If
the second call fails with not found, generally bmcweb will either
return 404, or fail to populate the property in the Redfish tree
depending on whether you're at collection level or resource level.

>
> - I also heard like the openBMC community nowadays not encouraging the extension approach into a generic repository for some reason unless there is a valid reason.

>From my perspective, these OEM extension mechanisms lead to a lack of
discussion and community effort on finding a generic solution.  In
some cases, they might be easier, but personally I think they're worse
for the project overall, even if they do let developers get features
done very quickly.

>
>
>
> For Option2,
>
> - I think bmcweb providing a configuration option (ibm-management-console) to use IBM implementation so the new OEM daemon interfaces can be used as OEM code inside the bmcweb so, that we can avoid the above problem from an external interface user perspective for different system platforms.

If you want to put everything within the ibm/v1 tree, feel free, but
make sure you read up on the discussions about the resources that are
there that happened in the past.  ibm/v1 is separate from the redfish
tree, and has some consequences because of that.  With that said, I'm
a little surprised these are OEM records.  I would've assumed that
these guard records would largely just be controlling the "Status"
record on the Redfish tree, and allowing it to be PATCHed to disabled.
Is that what you were thinking?

>
>
>
> The question is, Where I can implement the new daemon? New repository or any other existing repository?

We discussed this in the TOF forum, and there were some concerns about
creating a new repository with a new maintainer, and there was a
desire for some sort of co-maintainership model with someone in good
standing in the community, so Ramesh can build up his standing.  Is
anyone else willing to help here?

>
>
>
> If New repository means phosphor-hw-isolation (with extension) or openpower-hw-isolation?
>
>
>
> Any different thoughts or suggestions on the above proposal?
>
>
> Regards,
> Ramesh I
> OpenBMC Developer
> Slack: @rameshi1
> Discord:  @Ramesh I
> E-mail: rameshi1 at in.ibm.com
>
>