D-bus model proposal for pay for access features

[Ed Tanous]

> Content-Type: text/html; charset="UTF-8"

First of all, please avoid sending html emails if you can. They don't
render properly on everyone's workflows.

On Fri, Apr 30, 2021 at 11:15 AM Ratan Gupta <ratankgupta31 at gmail.com> wrote:
>
> Hi All,
>
> I would like to introduce a dbus model proposal around pay for access features.Normally IBM system ships with more hardware than was purchased, which can be unlocked later.

It would be great to get a lot more background here.  On its nose,
this seems like this polar opposite of open firmware and something
that, if done wrong, could be very harmful to the goals of the
project.  Assuming you did this, wouldn't anyone be able to simply
recompile the code with the license checks disabled, load it on the
system, and enable whatever they want without licenses?  That seems
like something you didn't intend, and something that's less likely on
closed source firmware, but probably needs considered in this design.

As-is, I'm not sure which side of the line I come down on, but my two
initial thoughts are:
1. I don't want to support it or help the code in any way, but IBM can
check this into their own specific interfaces.
2. This is harmful to the intent of OpenBMC and open source firmware
as a whole, and shouldn't be supported in any capacity in the OpenBMC
codebase.

I think a lot more background and details than what was provided in
the initial email are needed before jumping to "what does the dbus
interface look like" type discussions.

How would open firmware principals be retained if we're now supporting
firmware locking down systems?
Are patches allowed to circumvent the license checks?
Does IBM intend to not allow loading self-compiled firmware on their
systems to support this feature?
What is and isn't allowed to be locked down?
Can the license checks be entirely compiled out?
Do these licenses appear on any public interfaces?  How do we ensure
that the public interfaces aren't misused?  How do we keep standards
compliance (or do we not care)?
How does this affect our standing in things like OCP open system
firmware groups?  Does this OpenBMC systems that enable this feature
ineligible?

Those are the questions I have off the top of my head, and to
reiterate, this feels like the kind of thing that needs more than a
one sentence background statement before diving directly into designs.

>
> Features could be 1) AIX enabled/disabled
> 2) How many processors are enabled
> 3) How much memory is enabled
>
> Proposed Model:
>
> The model consists of following main entities:1 - licenses - these objects represents the features.  There will be a license represnting
> feature(one is to one relation ship) and these objects have state - active, inactive, unknown, etc.
> These objects could implement the Delete interface for when a client wishes to disable the license/feature.
>
> 2 - manager - the manager object (distinct from freedesktop object manager) provides a method
> interface to create new license objects.
>
> Alternate Dbus Model:
>
> 1 - Licenses: these objects represent an agreement.  These objects have an
> association to one or more features, and these objects have state - active,inactive, unknown, etc.
> These objects could implement the Delete interface for when a client wishes to disable the license.
>
> 2 - Features: these objects describe the features available.
> Feature objects would be static and implementation/platform defined.  A BMC or host firmware update
> could potentially add or remove the available features exposed as dbus objects.  At the moment the
> only feature attribute I can think of is a name and the feature status.
>
> 3 Manager - the manager object (distinct from freedesktop object manager)
> provides a method interface to create new license objects.
>
> The difference between two models areIn the alternate Dbus model we are keeping the feature Dbus object and the License have an associated features
> In the proposed model we are only keeping the license D-bus object which represent the feature.
>
> Flow would be as below with the proposed model -1/ Manager object would be having interface like upload (License activation key)
> 2/ On IBM systems we send this key to the host firmware which activates the features
> 3/ Host Firmware sends the activated feature list to the BMC
> 4/ BMC creates the licenses for the activated features
>
> I suspect an implementation of the above flow is highly IBM specific,
> but I hope some of you have some feedback that might enable some collaboration.
> If not - where should we put this application?
>
> Ratan