D-bus model proposal for pay for access features

D-bus model proposal for pay for access features

[Ratan Gupta]

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

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.

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

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

Re: D-bus model proposal for pay for access features

[Ratan Gupta]

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

Hi Team,

Any comments on the below proposal?

Ratan

On Fri, Apr 30, 2021 at 11:45 PM Ratan Gupta <ratankgupta31@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.
>
> 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
>
>

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

Re: D-bus model proposal for pay for access features

[Mike Jones]

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

Ratan,

I am not qualified to comment on “how”, but I see value in a BMC that can license features. However, it should cover both hardware and firmware. I can imagine licensed algorithms implemented as firmware. 

Given that a licensed feature might impact availability of information via gui or service, it must support queries for availability so services can behave properly when enabled and disabled.

Mike

Sent from my iPad

> On May 4, 2021, at 1:43 AM, Ratan Gupta <ratankgupta31@gmail.com> wrote:
> 
> 
> Hi Team,
> 
> Any comments on the below proposal?
> 
> Ratan
> 
>> On Fri, Apr 30, 2021 at 11:45 PM Ratan Gupta <ratankgupta31@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.
>> 
>> 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 are
>> In 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

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

Re: 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@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

Re: D-bus model proposal for pay for access features

[Mike Jones]

> On May 4, 2021, at 11:02 AM, Ed Tanous <ed@tanous.net> wrote:
> 
>> 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@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.

Given that Redfish is a big tree of interfaces, is there a provision for custom interfaces?

For example, suppose I wanted some special ADI interface for some ADI functionality (like tell me the duty cycle of the PWM of regulator foo), assume it is public info/code for this discussion, is there a way to hook into the hierarchy and add interfacing without updating the Redfish specification?

Like is there a way to query and ask what special stuff is there and access it? Or knowing a prior where to look to access it?

Are there OBMC principles on these kinds of extensions? Like it is allowed or not? Like one can bend the Redfish conventions or not?

I have to assume that somebody has the need to do non-standard interfacing.



> 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

Re: D-bus model proposal for pay for access features

[Brad Bishop]

On Tue, May 04, 2021 at 10:02:19AM -0700, Ed Tanous wrote:
>> 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.

+1

>
>On Fri, Apr 30, 2021 at 11:15 AM Ratan Gupta <ratankgupta31@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.  
I will try to provide that here and in follow up discussion.

>On its nose,
>this seems like this polar opposite of open firmware 
You certainly aren't alone having this kind of a reaction to ideas like 
this and I can understand that point of view.  More on this below...

>and something
>that, if done wrong, could be very harmful to the goals of the
>project.
Can you elaborate on the goals of the project that would be harmed?

> Assuming you did this, wouldn't anyone be able to simply
>recompile the code with the license checks disabled, load it on the
>system
In our system design, the BMC is not doing the actual license 
verification.  It is only a proxy, providing an interface to a user 
interface application.

Further, we don't allow BMC code to be loaded that isn't signed by IBM, 
so unless I'm really missing something I don't think this can happen 
even, if the validation was being done on the BMC.

> 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.
We are happy to do this for now if that is the will of the community.  
The impetus is certainly on me to show that this is in fact a feature 
that server OEMs care about (if any of you are lurking, please jump in).

I'm pretty certain this is something many server OEMs do and will 
continue to do.  So let me ask you what is better?  A single place for 
those with the common use case to collaborate, or a bunch of one-offs, 
likely full of bugs and security problems.

>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.
If you don't mind I would like to hear more about the intent of OpenBMC,
and how any of this harms those intents.

>
>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.
Happy to provide more background and details but I'm not sure where to 
begin.  Any hints?

>
>How would open firmware principals be retained 
Can you elaborate on these principles?  I'm curious.  I may even 
document the answers :-)

>if we're now supporting firmware locking down systems?
Don't we already lock down systems with things like secure or verified 
boot?  Can you help me understand lock down better?

>Are patches allowed to circumvent the license checks?
I think I covered this above but for completeness, on IBM systems the 
checks are not be done by the BMC and only IBM signed firmware is 
allowed.

>Does IBM intend to not allow loading self-compiled firmware on their
>systems to support this feature?
That's correct - IBM only allows firmware signed by IBM to be installed 
on IBM systems.

>What is and isn't allowed to be locked down?
Maybe another question is why would we disallow anything here?

>Can the license checks be entirely compiled out?
Again in an IBM design the checks aren't done on the BMC.  But if 
someone had a design like that, and they contributed that code to 
OpenBMC I don't see any problem with compiling it out.

>Do these licenses appear on any public interfaces?  
Right, the whole point is to show these on some kind of external 
interface.

>How do we ensure
>that the public interfaces aren't misused?  
How do we ensure _any_ public interface isn't misused?  Why would 
ensuring that they aren't misued for these public interfaces be any 
different than any other?  I don't think I understand this question.

>How do we keep standards
>compliance (or do we not care)?
This is something that many server OEMs do so I would not be terribly 
suprised to see it find its way into a standard management interface 
someday.

>How does this affect our standing in things like OCP open system
>firmware groups?  
I wouldn't expect this to affect our standing in OCP in any way.

>Does this OpenBMC systems that enable this feature
>ineligible?
Do you mean to ask, do systems that configure OpenBMC with something 
like this enabled make them ineligible for some kind of OCP compliance?  
Probably, but isn't that a problem for those configuring OpenBMC in that 
way?  I would say if you are looking for OCP compliance, don't use this 
feature.

thx - brad

Re: D-bus model proposal for pay for access features

[Brad Bishop]

On Tue, May 04, 2021 at 03:18:43PM -0600, Mike Jones wrote:
>
>> 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.
>
>Given that Redfish is a big tree of interfaces, is there a provision for custom interfaces?
Yes.

>
>For example, suppose I wanted some special ADI interface for some ADI functionality (like tell me the duty cycle of the PWM of regulator foo), assume it is public info/code for this discussion, is there a way to hook into the hierarchy and add interfacing without updating the Redfish specification?
Yes - Most(all?) redfish properties have an "OEM" property.

>
>Like is there a way to query and ask what special stuff is there and access it? Or knowing a prior where to look to access it?
>
>Are there OBMC principles on these kinds of extensions? Like it is allowed or not? Like one can bend the Redfish conventions or not?
Ed or Gunnar can correct me if I'm wrong but I'm pretty sure the current 
rule is you have to make an attempt to get your "extensions" proposed to 
the DMTF at a minimum, before it will be considered for inclusion as an 
OEM property.  IBM and Intel do have a bunch of OEM properties that was 
added before that rule went into effect.

>
>I have to assume that somebody has the need to do non-standard interfacing.

I would go a step further and say "most" or even "everyone" has this 
need.

FWIW I have a love/hate relationship with this rule. I think its great 
because it really forces you to get your content into the spec, and 
thats good for OpenBMC and the industry.  I'm proud to say that IBM has 
gotten piles of content into the spec in the last 12 months or so as a 
direct result of this rule.

However, there is often still lots of other content that is absolutely 
required in products and adding that content to the spec may just not be 
a priority at the moment.  Also not everyone can invest in the resources 
to participate in the DMTF.  I think it would be great if we could do 
more to help these kinds of users (e.g. some kind of plug-in system).

-brad

Re: D-bus model proposal for pay for access features

[Ed Tanous]

On Tue, May 4, 2021 at 2:18 PM Mike Jones <proclivis@gmail.com> wrote:
>
>
>
> > On May 4, 2021, at 11:02 AM, Ed Tanous <ed@tanous.net> wrote:
> >
> >> 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@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.
>
> Given that Redfish is a big tree of interfaces, is there a provision for custom interfaces?

Yes, the term to search for in the Redfish spec is "OEM" properties,
which the spec can do more justice than I can.

>
> For example, suppose I wanted some special ADI interface for some ADI functionality (like tell me the duty cycle of the PWM of regulator foo), assume it is public info/code for this discussion, is there a way to hook into the hierarchy and add interfacing without updating the Redfish specification?

In this example you wouldn't do that.  Fans are already well modeled
in Redfish, as are a lot of other things you're likely to do with a VR
(update firmware, stream telemetry values, monitor status, ect).

>
> Like is there a way to query and ask what special stuff is there and access it? Or knowing a prior where to look to access it?

Yes.  Oem extensions are the specifications answer.

>
> Are there OBMC principles on these kinds of extensions? Like it is allowed or not? Like one can bend the Redfish conventions or not?

Currently OEM policy is here, and can do more justice than I can.
https://github.com/openbmc/bmcweb/blob/master/OEM_SCHEMAS.md

FWIW, I don't think we've arrived at the best policy in terms of OEM
schemas, but considering the influx of "should be standard" OEM
properties that were coming in, and the quality of them in general,
this was a necessary reaction (and has largely yielded positive
results IMO).  Like anything in OpenBMC, it is subject to evolve over
time and with more people's input.

>
> I have to assume that somebody has the need to do non-standard interfacing.
>
>
>
> > 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
>

Re: D-bus model proposal for pay for access features

[Patrick Williams]

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

Brad,

I've reshuffled some of the quotes around because it makes more sense
with the points I'd like to make.  I've tried to add color to what I
think the OCP perspective would be.

Typical disclosure: these are my thoughts, not my employer.  I am not
a lawyer.  Blah blah blah.

On Tue, May 04, 2021 at 07:38:43PM -0400, Brad Bishop wrote:
> On Tue, May 04, 2021 at 10:02:19AM -0700, Ed Tanous wrote:
> >How does this affect our standing in things like OCP open system
> >firmware groups?  
> I wouldn't expect this to affect our standing in OCP in any way.
> 
> >Does this OpenBMC systems that enable this feature
> >ineligible?
> Do you mean to ask, do systems that configure OpenBMC with something 
> like this enabled make them ineligible for some kind of OCP compliance?  
> Probably, but isn't that a problem for those configuring OpenBMC in that 
> way?  I would say if you are looking for OCP compliance, don't use this 
> feature.

I'm glad things were broken out this way because both of these questions
need to be resolved.

I agree that the presence of this feature, or any feature which isn't a
violation of widely accepted ethical guidelines[1], should not on its
own affect our standing in or usage by other communities.  But, it can
certainly affect their opinion of us, which can diminish our standing.

The other question is: would OCP accept the usage of this feature in an
OCP Accepted / Inspired[2] system?  I strongly suspect the answer here
is no.  It isn't just this feature, but this feature coupled with the
code signing, which is what would cause the denial of certification.

OCP machines are expected to be owned by the entity that purchased it
and not the manufacturer.  To quote from an OCP website[3]:

    Open system firmware is an open development project, the goal of which
    is to allow OCP owners to "own their firmware" -- to move the point of
    control of firmware to the system owner. Owners must be able to change
    firmware and share it -- including any binary components -- with other
    owners. Starting in March, 2021, OCP badging for servers will require
    that systems support OSF.

Compliance with this statement would render any firmware-based license
enforcement moot.  (Note that this above OCP statement is in reference
to OSF, the UEFI implementation, but I think the intention is reflected
elsewhere in BMC expectations.)

This is very important to both OCP and Facebook for the obvious reasons
that it allows us to enhance the server firmware to suit our own
purposes but also the non-obvious reason that it reduces the
environmental impact of our business[7].  If ownership of the firmware
is a one-way door (either us or the OEM/ODM), it means there are more
components which have to be scrapped when the servers are decommisioned.
If we can transfer ownership, in a secure manner, those parts are then
able to be reused and/or repurposed.  ITRenew is one company I am aware
of facilitates this kind of reuse[8]; they are a platinum member of OCP
and Sri hangs out on the OpenBMC Discord.

> > Assuming you did this, wouldn't anyone be able to simply
> >recompile the code with the license checks disabled, load it on the
> >system
> In our system design, the BMC is not doing the actual license 
> verification.  It is only a proxy, providing an interface to a user 
> interface application.
> 
> Further, we don't allow BMC code to be loaded that isn't signed by IBM, 
> so unless I'm really missing something I don't think this can happen 
> even, if the validation was being done on the BMC.

This feature was originally presented to us as being used to activate
"unlicensed" hardware or enforce license agreements with your OS.
While I think that is a lousy business model, that is between you and
your customers.

But, IBM (and other OEMs[4]) also uses this feature to prevent people
from applying IBM-signed firmware updates to their own machines,
unless they have a current maintenance contract.  So when we have a
CVE in some software package used by OpenBMC not only can a machine
owner not compile their own fix for their own machine but they can't
even apply the fix already compiled by IBM unless they cough up
additional money.  This behavior is why I used the phrase "openly
hostile to your customers."

IBM calls this entitlement to install firmware updates an "Update
Access Key"[5].  The referenced website describes how the machine
will only accept firmware updates if the UAK is not expired, how the
original UAK aligns with the system warranty, and how you can get
additional ones after this point (expiring every 180 days) if you
have an "IBM hardware maintenance service agreement".

This behavior, and not the hardware licensing, is a big motivating
factor in why I said "I have no interest in providing any assistance on
this feature" and do not feel the project should support it either.
You might say "well, we'll just keep this part of the code private
then", and it would likely be pretty trivial to privately hold a few
patches to phosphor-bmc-code-mgmt to do the UAK work once you have
the rest of the framework in place.  The triviality of it is partially
why I don't even want the framework in place.  This feature provides no
benefit to anyone except <<insert OEM>>'s [bad] business model and provides
no benefit to users or this community (and I'll posit later it actually
harms this community).

> >if we're now supporting firmware locking down systems?
> Don't we already lock down systems with things like secure or verified 
> boot?  Can you help me understand lock down better?

Yes, we support secure / verified boot, even on OCP servers.  But the
OCP model is that the machine owner owns the machine, not the ODM/OEM.
The other model, which is what you're doing, is only advantageous to
you (and is deterimental to everyone else).  This isn't a matter of lack 
of technical capability because IBM's own security research team provided
a whitepaper to OCP on best practices for providing transfering ownership
of the device firmware to the machine owner[6].

> I'm pretty certain this is something many server OEMs do and will 
> continue to do.  So let me ask you what is better?  A single place for 
> those with the common use case to collaborate, or a bunch of one-offs, 
> likely full of bugs and security problems.

If I had to make a choice between supporting code that is a net-negative
to the community or letting you make a buggy implementation of a bad
feature... letting you make a buggy implementation is a double-win to
me because if you fail in implementing this it means [various people with
an ability to reverse-engineer] it can **help** users by giving them a
way around your terrible firmware update lockout.  

> >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.
> If you don't mind I would like to hear more about the intent of OpenBMC,
> and how any of this harms those intents.

> >How would open firmware principals be retained 
> Can you elaborate on these principles?  I'm curious.  I may even 
> document the answers :-)

I've badgered enough on the firmware update side of this, which is
the primary hinderance to "open firmware principles" I see.

On Discord I said that I didn't think this feature is in the "spirit of
open source software" and I think Ed's statement here is along those
lines, but I realize there is a lot of potential perspective encapsulated
in that one phrase so let me try to unpack it.

Corporate attachment to the Open Source / Free Software movement has
often been around the collaboration (and thus deduplication of effort)
side of it, but that is an outcome and not a principle of open source.
To me the draw has always been about freedom to read, debug and modify
the source.  It is immensely frustrating to me when I have to use non-free
software and I find a bug: you have no visibility into what is going
wrong and you have no possibility of fixing it!  As the GNU/FSF often
states it: "'free software' is a matter of liberty, not price... you
should think of 'free' as in 'free speech' and not as in 'free beer'.[9]"

Again I bring up firmware update, but the emergence of GPLv3 (and
similar licenses) was instigated in response to the the Tivoization
of consumer devices[10].

[ Side question: are you sure your statement that "only IBM signed
  firmware can run on our machines" doesn't violate the terms of the
  GPLv3, which is used by a good number of packages used in OpenBMC? ]

We often have people show up to the project with some 5 year old server
they bought off eBay asking "how do I get OpenBMC to run on this?"
Which is a worse answer?:
    1. Well, we don't currently support it specifically but we support
       <XYZ> which is based on the same reference design.  With a little
       bit of reverse engineering, or the schematics from the
       manufacturer, you could probably create a port.

    2. Yeah, we completely support that machine, but unfortunately the
       manufacturer locked down the system in a way so that you can
       compile all the code but the machine won't recognize it.  And if
       I told you how to bypass that, the manufacturer could sue me for
       violating the DMCA[11] because the same bug that allows you to
       bypass their signing is still present on their current systems.

IBM does great work on this project and having upstream machine support
is good.  But, there is a big part of me that would much rather answer
#1 than #2 because of the implications from a Software Freedom
perspective.

> >and something
> >that, if done wrong, could be very harmful to the goals of the
> >project.
> Can you elaborate on the goals of the project that would be harmed?

I hinted at the DMCA above.  The inclusion of this feature by the project
pushes DMCA risk onto me, a developer on this project, from IBM.

A long time ago now, I did an internship at IBM and at the time someone
had figured out how to circumvent exactly this feature on Power3/Power4
AS/400 servers and was contacting IBM customers to sell them black-market
activation keys (my cubical happened to share a wall with one of the
inventors of the hardware used at the time to confirm the activation
keys so I got to hear plenty of details on this).  The DMCA was new at
the time and first applied for protecting from DVD copyright, but I have
no doubt that if this situation happened today IBM would leverage the
DMCA to stop this rather quickly (and honestly, rightly so).

The problem is that the DMCA has also been leveraged for cases which are
not a direct theft-of-service[12].  I am not saying that IBM will, and I
can't expect you to get a committment on that, but you are pushing the
risk onto me, the other developers here, and the project as a whole.

What am I even talking about, you're probably wondering?  Since IBM is
using this feature to protect your intellectual property (AIX licenses,
firmware update lockout, etc.) everything about it falls under the
purview of the DMCA.  If I find a bug in your open source implementation
and report it in a public forum, you could issue a DMCA take-down
request.  If I review a code change and conceive of a way it might be
used to circumvent your implementation, and I bring it to your
attention, you could issue a DMCA take-down request.  If someone comes
to us with a 5 year old server and we figure out how to bypass your
security lockout so they can flash on the Github version of OpenBMC, you
could issue a DMCA take-down request.  If I do a presentation on
debugging with dbus and it turns out someone figures out how to use that
information to circumvent your licensing feature on the SSH interface,
you could issue a DMCA take-down request.

These might sound absurd or you might think "IBM would never do that."
How do I and the other developers here know?  You're asking us to take
on that risk.  And why should I?  I want to stay as far away from
anything related to your licensing feature as I possibly can.  It does
nothing good for your customers, it does nothing good for this project,
and it puts me, a developer, at potential legal risk.

While you might have a little bit of code that you're sharing, that
maybe other companies can leverage, you are also giving us baggage
that reduces our collaboration.  Now, anytime I'm even close to this
code, I have to think about not only the technical but now legal
ramifications of what I'm doing.  That means, I'm quite likely going to
have to just say "do whatever you want and leave me out of it" anytime
this code comes up in reviews or discussions.

-- References --

1. https://www.acm.org/code-of-ethics
2. https://www.opencompute.org/products#ocp-accepted-inspired-modal
3. https://www.opencompute.org/projects/open-system-firmware
4. https://www.zdnet.com/article/hp-to-begin-charging-for-firmware-updates-and-service-packs-for-servers/
5. https://www.ibm.com/support/pages/management-power8-and-later-update-access-keys#q45
6. https://www.opencompute.org/documents/ibm-white-paper-ownership-and-control-of-firmware-in-open-compute-project-devices
7. https://www.theguardian.com/technology/2021/apr/16/facebook-says-it-has-reached-net-zero-emissions
8. https://www.itrenew.com/resources/the-tco-of-ocp/
9. https://www.gnu.org/philosophy/free-sw.en.html
10. https://en.wikipedia.org/wiki/Tivoization
11. https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act
12. https://www.eff.org/wp/unintended-consequences-16-years-under-dmca

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

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

Hi Patrick,

Re-starting this discussion with the design that is being worked at 
License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code 
Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.

I agree with your concern about using this feature for letting the BMC 
software or resources licensed. We should reduce the scope of this 
design to exclude this from controlling the driver updates on the BMC.

But as we have the DMTF approved redfish schema for the LicenseService, 
we would like to bring this into the OpenBMC. We can use this License 
Manager as a pass through application at BMC. With this application and 
interfaces, user can upload the license for the hardware parts and for 
the installation of any OS on top of the firmware. There will be no 
validation of the License at the BMC scope. All 
validation/interpretation of the License will be at the hypervisor or 
the operating system level.

We are looking for views from you and the community.

Thanks & Regards,
Sunitha

On 05-05-2021 23:06, Patrick Williams wrote:
> Brad,
>
> I've reshuffled some of the quotes around because it makes more sense
> with the points I'd like to make.  I've tried to add color to what I
> think the OCP perspective would be.
>
> Typical disclosure: these are my thoughts, not my employer.  I am not
> a lawyer.  Blah blah blah.
>
> On Tue, May 04, 2021 at 07:38:43PM -0400, Brad Bishop wrote:
>> On Tue, May 04, 2021 at 10:02:19AM -0700, Ed Tanous wrote:
>>> How does this affect our standing in things like OCP open system
>>> firmware groups?
>> I wouldn't expect this to affect our standing in OCP in any way.
>>
>>> Does this OpenBMC systems that enable this feature
>>> ineligible?
>> Do you mean to ask, do systems that configure OpenBMC with something
>> like this enabled make them ineligible for some kind of OCP compliance?
>> Probably, but isn't that a problem for those configuring OpenBMC in that
>> way?  I would say if you are looking for OCP compliance, don't use this
>> feature.
> I'm glad things were broken out this way because both of these questions
> need to be resolved.
>
> I agree that the presence of this feature, or any feature which isn't a
> violation of widely accepted ethical guidelines[1], should not on its
> own affect our standing in or usage by other communities.  But, it can
> certainly affect their opinion of us, which can diminish our standing.
>
> The other question is: would OCP accept the usage of this feature in an
> OCP Accepted / Inspired[2] system?  I strongly suspect the answer here
> is no.  It isn't just this feature, but this feature coupled with the
> code signing, which is what would cause the denial of certification.
>
> OCP machines are expected to be owned by the entity that purchased it
> and not the manufacturer.  To quote from an OCP website[3]:
>
>      Open system firmware is an open development project, the goal of which
>      is to allow OCP owners to "own their firmware" -- to move the point of
>      control of firmware to the system owner. Owners must be able to change
>      firmware and share it -- including any binary components -- with other
>      owners. Starting in March, 2021, OCP badging for servers will require
>      that systems support OSF.
>
> Compliance with this statement would render any firmware-based license
> enforcement moot.  (Note that this above OCP statement is in reference
> to OSF, the UEFI implementation, but I think the intention is reflected
> elsewhere in BMC expectations.)
>
> This is very important to both OCP and Facebook for the obvious reasons
> that it allows us to enhance the server firmware to suit our own
> purposes but also the non-obvious reason that it reduces the
> environmental impact of our business[7].  If ownership of the firmware
> is a one-way door (either us or the OEM/ODM), it means there are more
> components which have to be scrapped when the servers are decommisioned.
> If we can transfer ownership, in a secure manner, those parts are then
> able to be reused and/or repurposed.  ITRenew is one company I am aware
> of facilitates this kind of reuse[8]; they are a platinum member of OCP
> and Sri hangs out on the OpenBMC Discord.
>
>>> Assuming you did this, wouldn't anyone be able to simply
>>> recompile the code with the license checks disabled, load it on the
>>> system
>> In our system design, the BMC is not doing the actual license
>> verification.  It is only a proxy, providing an interface to a user
>> interface application.
>>
>> Further, we don't allow BMC code to be loaded that isn't signed by IBM,
>> so unless I'm really missing something I don't think this can happen
>> even, if the validation was being done on the BMC.
> This feature was originally presented to us as being used to activate
> "unlicensed" hardware or enforce license agreements with your OS.
> While I think that is a lousy business model, that is between you and
> your customers.
>
> But, IBM (and other OEMs[4]) also uses this feature to prevent people
> from applying IBM-signed firmware updates to their own machines,
> unless they have a current maintenance contract.  So when we have a
> CVE in some software package used by OpenBMC not only can a machine
> owner not compile their own fix for their own machine but they can't
> even apply the fix already compiled by IBM unless they cough up
> additional money.  This behavior is why I used the phrase "openly
> hostile to your customers."
>
> IBM calls this entitlement to install firmware updates an "Update
> Access Key"[5].  The referenced website describes how the machine
> will only accept firmware updates if the UAK is not expired, how the
> original UAK aligns with the system warranty, and how you can get
> additional ones after this point (expiring every 180 days) if you
> have an "IBM hardware maintenance service agreement".
>
> This behavior, and not the hardware licensing, is a big motivating
> factor in why I said "I have no interest in providing any assistance on
> this feature" and do not feel the project should support it either.
> You might say "well, we'll just keep this part of the code private
> then", and it would likely be pretty trivial to privately hold a few
> patches to phosphor-bmc-code-mgmt to do the UAK work once you have
> the rest of the framework in place.  The triviality of it is partially
> why I don't even want the framework in place.  This feature provides no
> benefit to anyone except <<insert OEM>>'s [bad] business model and provides
> no benefit to users or this community (and I'll posit later it actually
> harms this community).
>
>>> if we're now supporting firmware locking down systems?
>> Don't we already lock down systems with things like secure or verified
>> boot?  Can you help me understand lock down better?
> Yes, we support secure / verified boot, even on OCP servers.  But the
> OCP model is that the machine owner owns the machine, not the ODM/OEM.
> The other model, which is what you're doing, is only advantageous to
> you (and is deterimental to everyone else).  This isn't a matter of lack
> of technical capability because IBM's own security research team provided
> a whitepaper to OCP on best practices for providing transfering ownership
> of the device firmware to the machine owner[6].
>
>> I'm pretty certain this is something many server OEMs do and will
>> continue to do.  So let me ask you what is better?  A single place for
>> those with the common use case to collaborate, or a bunch of one-offs,
>> likely full of bugs and security problems.
> If I had to make a choice between supporting code that is a net-negative
> to the community or letting you make a buggy implementation of a bad
> feature... letting you make a buggy implementation is a double-win to
> me because if you fail in implementing this it means [various people with
> an ability to reverse-engineer] it can **help** users by giving them a
> way around your terrible firmware update lockout.
>
>>> 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.
>> If you don't mind I would like to hear more about the intent of OpenBMC,
>> and how any of this harms those intents.
>>> How would open firmware principals be retained
>> Can you elaborate on these principles?  I'm curious.  I may even
>> document the answers :-)
> I've badgered enough on the firmware update side of this, which is
> the primary hinderance to "open firmware principles" I see.
>
> On Discord I said that I didn't think this feature is in the "spirit of
> open source software" and I think Ed's statement here is along those
> lines, but I realize there is a lot of potential perspective encapsulated
> in that one phrase so let me try to unpack it.
>
> Corporate attachment to the Open Source / Free Software movement has
> often been around the collaboration (and thus deduplication of effort)
> side of it, but that is an outcome and not a principle of open source.
> To me the draw has always been about freedom to read, debug and modify
> the source.  It is immensely frustrating to me when I have to use non-free
> software and I find a bug: you have no visibility into what is going
> wrong and you have no possibility of fixing it!  As the GNU/FSF often
> states it: "'free software' is a matter of liberty, not price... you
> should think of 'free' as in 'free speech' and not as in 'free beer'.[9]"
>
> Again I bring up firmware update, but the emergence of GPLv3 (and
> similar licenses) was instigated in response to the the Tivoization
> of consumer devices[10].
>
> [ Side question: are you sure your statement that "only IBM signed
>    firmware can run on our machines" doesn't violate the terms of the
>    GPLv3, which is used by a good number of packages used in OpenBMC? ]
>
> We often have people show up to the project with some 5 year old server
> they bought off eBay asking "how do I get OpenBMC to run on this?"
> Which is a worse answer?:
>      1. Well, we don't currently support it specifically but we support
>         <XYZ> which is based on the same reference design.  With a little
>         bit of reverse engineering, or the schematics from the
>         manufacturer, you could probably create a port.
>
>      2. Yeah, we completely support that machine, but unfortunately the
>         manufacturer locked down the system in a way so that you can
>         compile all the code but the machine won't recognize it.  And if
>         I told you how to bypass that, the manufacturer could sue me for
>         violating the DMCA[11] because the same bug that allows you to
>         bypass their signing is still present on their current systems.
>
> IBM does great work on this project and having upstream machine support
> is good.  But, there is a big part of me that would much rather answer
> #1 than #2 because of the implications from a Software Freedom
> perspective.
>
>>> and something
>>> that, if done wrong, could be very harmful to the goals of the
>>> project.
>> Can you elaborate on the goals of the project that would be harmed?
> I hinted at the DMCA above.  The inclusion of this feature by the project
> pushes DMCA risk onto me, a developer on this project, from IBM.
>
> A long time ago now, I did an internship at IBM and at the time someone
> had figured out how to circumvent exactly this feature on Power3/Power4
> AS/400 servers and was contacting IBM customers to sell them black-market
> activation keys (my cubical happened to share a wall with one of the
> inventors of the hardware used at the time to confirm the activation
> keys so I got to hear plenty of details on this).  The DMCA was new at
> the time and first applied for protecting from DVD copyright, but I have
> no doubt that if this situation happened today IBM would leverage the
> DMCA to stop this rather quickly (and honestly, rightly so).
>
> The problem is that the DMCA has also been leveraged for cases which are
> not a direct theft-of-service[12].  I am not saying that IBM will, and I
> can't expect you to get a committment on that, but you are pushing the
> risk onto me, the other developers here, and the project as a whole.
>
> What am I even talking about, you're probably wondering?  Since IBM is
> using this feature to protect your intellectual property (AIX licenses,
> firmware update lockout, etc.) everything about it falls under the
> purview of the DMCA.  If I find a bug in your open source implementation
> and report it in a public forum, you could issue a DMCA take-down
> request.  If I review a code change and conceive of a way it might be
> used to circumvent your implementation, and I bring it to your
> attention, you could issue a DMCA take-down request.  If someone comes
> to us with a 5 year old server and we figure out how to bypass your
> security lockout so they can flash on the Github version of OpenBMC, you
> could issue a DMCA take-down request.  If I do a presentation on
> debugging with dbus and it turns out someone figures out how to use that
> information to circumvent your licensing feature on the SSH interface,
> you could issue a DMCA take-down request.
>
> These might sound absurd or you might think "IBM would never do that."
> How do I and the other developers here know?  You're asking us to take
> on that risk.  And why should I?  I want to stay as far away from
> anything related to your licensing feature as I possibly can.  It does
> nothing good for your customers, it does nothing good for this project,
> and it puts me, a developer, at potential legal risk.
>
> While you might have a little bit of code that you're sharing, that
> maybe other companies can leverage, you are also giving us baggage
> that reduces our collaboration.  Now, anytime I'm even close to this
> code, I have to think about not only the technical but now legal
> ramifications of what I'm doing.  That means, I'm quite likely going to
> have to just say "do whatever you want and leave me out of it" anytime
> this code comes up in reviews or discussions.
>
> -- References --
>
> 1.https://www.acm.org/code-of-ethics
> 2.https://www.opencompute.org/products#ocp-accepted-inspired-modal
> 3.https://www.opencompute.org/projects/open-system-firmware
> 4.https://www.zdnet.com/article/hp-to-begin-charging-for-firmware-updates-and-service-packs-for-servers/
> 5.https://www.ibm.com/support/pages/management-power8-and-later-update-access-keys#q45
> 6.https://www.opencompute.org/documents/ibm-white-paper-ownership-and-control-of-firmware-in-open-compute-project-devices
> 7.https://www.theguardian.com/technology/2021/apr/16/facebook-says-it-has-reached-net-zero-emissions
> 8.https://www.itrenew.com/resources/the-tco-of-ocp/
> 9.https://www.gnu.org/philosophy/free-sw.en.html
> 10.https://en.wikipedia.org/wiki/Tivoization
> 11.https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act
> 12.https://www.eff.org/wp/unintended-consequences-16-years-under-dmca
>

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

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Patrick Williams]

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

On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
> Hi Patrick,
> 
> Re-starting this discussion with the design that is being worked at 
> License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code 
> Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.

I've already written enough on this topic.  You've not added much in
terms of what I've already written, so I'm not sure what more you want
me to say.

> I agree with your concern about using this feature for letting the BMC 
> software or resources licensed. We should reduce the scope of this 
> design to exclude this from controlling the driver updates on the BMC.

Once you have the license manager on the BMC, there isn't anything that
would stop you from adding patches on your own to block BMC updates
without license approvals (which I really can't do anything to stop you
from doing it on your own anyhow, and I'm not suggesting I can).  This
still doesn't do anything to protect me from legal risks I would have 
to take on with this feature.

> But as we have the DMTF approved redfish schema for the LicenseService, 
> we would like to bring this into the OpenBMC. We can use this License 
> Manager as a pass through application at BMC. With this application and 
> interfaces, user can upload the license for the hardware parts and for 
> the installation of any OS on top of the firmware. There will be no 
> validation of the License at the BMC scope. All 
> validation/interpretation of the License will be at the hypervisor or 
> the operating system level.

So you're going to add some custom PLDM commands to offload this to your
host firmware.  How is this helpful to the rest of the community?
Again, why do I want to take on the maintenance risk and legal risk
associated with this feature?  Why would anyone else in the community?

> We are looking for views from you and the community.

You've got to show that this feature is somehow enough of a benefit to
the community that justifies the risks.  Or you have to have some
proposal that mitigates the risks.  "Redfish defined a schema" is
not a benefit on its own.

Have you talked with your legal team about my DMCA concerns?  If you
can't provide some kind of assurance that developers on this project are
not going to be subject to a DMCA takedown notice because of YOUR code
and YOUR feature, I don't know how you can expect anyone on the project
to want to touch this.

> Thanks & Regards,
> Sunitha
> 
> On 05-05-2021 23:06, Patrick Williams wrote:
> > Brad,
> >
> > I've reshuffled some of the quotes around because it makes more sense
> > with the points I'd like to make.  I've tried to add color to what I
> > think the OCP perspective would be.
> >
> > Typical disclosure: these are my thoughts, not my employer.  I am not
> > a lawyer.  Blah blah blah.
> >
> > On Tue, May 04, 2021 at 07:38:43PM -0400, Brad Bishop wrote:
> >> On Tue, May 04, 2021 at 10:02:19AM -0700, Ed Tanous wrote:
> >>> How does this affect our standing in things like OCP open system
> >>> firmware groups?
> >> I wouldn't expect this to affect our standing in OCP in any way.
> >>
> >>> Does this OpenBMC systems that enable this feature
> >>> ineligible?
> >> Do you mean to ask, do systems that configure OpenBMC with something
> >> like this enabled make them ineligible for some kind of OCP compliance?
> >> Probably, but isn't that a problem for those configuring OpenBMC in that
> >> way?  I would say if you are looking for OCP compliance, don't use this
> >> feature.
> > I'm glad things were broken out this way because both of these questions
> > need to be resolved.
> >
> > I agree that the presence of this feature, or any feature which isn't a
> > violation of widely accepted ethical guidelines[1], should not on its
> > own affect our standing in or usage by other communities.  But, it can
> > certainly affect their opinion of us, which can diminish our standing.
> >
> > The other question is: would OCP accept the usage of this feature in an
> > OCP Accepted / Inspired[2] system?  I strongly suspect the answer here
> > is no.  It isn't just this feature, but this feature coupled with the
> > code signing, which is what would cause the denial of certification.
> >
> > OCP machines are expected to be owned by the entity that purchased it
> > and not the manufacturer.  To quote from an OCP website[3]:
> >
> >      Open system firmware is an open development project, the goal of which
> >      is to allow OCP owners to "own their firmware" -- to move the point of
> >      control of firmware to the system owner. Owners must be able to change
> >      firmware and share it -- including any binary components -- with other
> >      owners. Starting in March, 2021, OCP badging for servers will require
> >      that systems support OSF.
> >
> > Compliance with this statement would render any firmware-based license
> > enforcement moot.  (Note that this above OCP statement is in reference
> > to OSF, the UEFI implementation, but I think the intention is reflected
> > elsewhere in BMC expectations.)
> >
> > This is very important to both OCP and Facebook for the obvious reasons
> > that it allows us to enhance the server firmware to suit our own
> > purposes but also the non-obvious reason that it reduces the
> > environmental impact of our business[7].  If ownership of the firmware
> > is a one-way door (either us or the OEM/ODM), it means there are more
> > components which have to be scrapped when the servers are decommisioned.
> > If we can transfer ownership, in a secure manner, those parts are then
> > able to be reused and/or repurposed.  ITRenew is one company I am aware
> > of facilitates this kind of reuse[8]; they are a platinum member of OCP
> > and Sri hangs out on the OpenBMC Discord.
> >
> >>> Assuming you did this, wouldn't anyone be able to simply
> >>> recompile the code with the license checks disabled, load it on the
> >>> system
> >> In our system design, the BMC is not doing the actual license
> >> verification.  It is only a proxy, providing an interface to a user
> >> interface application.
> >>
> >> Further, we don't allow BMC code to be loaded that isn't signed by IBM,
> >> so unless I'm really missing something I don't think this can happen
> >> even, if the validation was being done on the BMC.
> > This feature was originally presented to us as being used to activate
> > "unlicensed" hardware or enforce license agreements with your OS.
> > While I think that is a lousy business model, that is between you and
> > your customers.
> >
> > But, IBM (and other OEMs[4]) also uses this feature to prevent people
> > from applying IBM-signed firmware updates to their own machines,
> > unless they have a current maintenance contract.  So when we have a
> > CVE in some software package used by OpenBMC not only can a machine
> > owner not compile their own fix for their own machine but they can't
> > even apply the fix already compiled by IBM unless they cough up
> > additional money.  This behavior is why I used the phrase "openly
> > hostile to your customers."
> >
> > IBM calls this entitlement to install firmware updates an "Update
> > Access Key"[5].  The referenced website describes how the machine
> > will only accept firmware updates if the UAK is not expired, how the
> > original UAK aligns with the system warranty, and how you can get
> > additional ones after this point (expiring every 180 days) if you
> > have an "IBM hardware maintenance service agreement".
> >
> > This behavior, and not the hardware licensing, is a big motivating
> > factor in why I said "I have no interest in providing any assistance on
> > this feature" and do not feel the project should support it either.
> > You might say "well, we'll just keep this part of the code private
> > then", and it would likely be pretty trivial to privately hold a few
> > patches to phosphor-bmc-code-mgmt to do the UAK work once you have
> > the rest of the framework in place.  The triviality of it is partially
> > why I don't even want the framework in place.  This feature provides no
> > benefit to anyone except <<insert OEM>>'s [bad] business model and provides
> > no benefit to users or this community (and I'll posit later it actually
> > harms this community).
> >
> >>> if we're now supporting firmware locking down systems?
> >> Don't we already lock down systems with things like secure or verified
> >> boot?  Can you help me understand lock down better?
> > Yes, we support secure / verified boot, even on OCP servers.  But the
> > OCP model is that the machine owner owns the machine, not the ODM/OEM.
> > The other model, which is what you're doing, is only advantageous to
> > you (and is deterimental to everyone else).  This isn't a matter of lack
> > of technical capability because IBM's own security research team provided
> > a whitepaper to OCP on best practices for providing transfering ownership
> > of the device firmware to the machine owner[6].
> >
> >> I'm pretty certain this is something many server OEMs do and will
> >> continue to do.  So let me ask you what is better?  A single place for
> >> those with the common use case to collaborate, or a bunch of one-offs,
> >> likely full of bugs and security problems.
> > If I had to make a choice between supporting code that is a net-negative
> > to the community or letting you make a buggy implementation of a bad
> > feature... letting you make a buggy implementation is a double-win to
> > me because if you fail in implementing this it means [various people with
> > an ability to reverse-engineer] it can **help** users by giving them a
> > way around your terrible firmware update lockout.
> >
> >>> 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.
> >> If you don't mind I would like to hear more about the intent of OpenBMC,
> >> and how any of this harms those intents.
> >>> How would open firmware principals be retained
> >> Can you elaborate on these principles?  I'm curious.  I may even
> >> document the answers :-)
> > I've badgered enough on the firmware update side of this, which is
> > the primary hinderance to "open firmware principles" I see.
> >
> > On Discord I said that I didn't think this feature is in the "spirit of
> > open source software" and I think Ed's statement here is along those
> > lines, but I realize there is a lot of potential perspective encapsulated
> > in that one phrase so let me try to unpack it.
> >
> > Corporate attachment to the Open Source / Free Software movement has
> > often been around the collaboration (and thus deduplication of effort)
> > side of it, but that is an outcome and not a principle of open source.
> > To me the draw has always been about freedom to read, debug and modify
> > the source.  It is immensely frustrating to me when I have to use non-free
> > software and I find a bug: you have no visibility into what is going
> > wrong and you have no possibility of fixing it!  As the GNU/FSF often
> > states it: "'free software' is a matter of liberty, not price... you
> > should think of 'free' as in 'free speech' and not as in 'free beer'.[9]"
> >
> > Again I bring up firmware update, but the emergence of GPLv3 (and
> > similar licenses) was instigated in response to the the Tivoization
> > of consumer devices[10].
> >
> > [ Side question: are you sure your statement that "only IBM signed
> >    firmware can run on our machines" doesn't violate the terms of the
> >    GPLv3, which is used by a good number of packages used in OpenBMC? ]
> >
> > We often have people show up to the project with some 5 year old server
> > they bought off eBay asking "how do I get OpenBMC to run on this?"
> > Which is a worse answer?:
> >      1. Well, we don't currently support it specifically but we support
> >         <XYZ> which is based on the same reference design.  With a little
> >         bit of reverse engineering, or the schematics from the
> >         manufacturer, you could probably create a port.
> >
> >      2. Yeah, we completely support that machine, but unfortunately the
> >         manufacturer locked down the system in a way so that you can
> >         compile all the code but the machine won't recognize it.  And if
> >         I told you how to bypass that, the manufacturer could sue me for
> >         violating the DMCA[11] because the same bug that allows you to
> >         bypass their signing is still present on their current systems.
> >
> > IBM does great work on this project and having upstream machine support
> > is good.  But, there is a big part of me that would much rather answer
> > #1 than #2 because of the implications from a Software Freedom
> > perspective.
> >
> >>> and something
> >>> that, if done wrong, could be very harmful to the goals of the
> >>> project.
> >> Can you elaborate on the goals of the project that would be harmed?
> > I hinted at the DMCA above.  The inclusion of this feature by the project
> > pushes DMCA risk onto me, a developer on this project, from IBM.
> >
> > A long time ago now, I did an internship at IBM and at the time someone
> > had figured out how to circumvent exactly this feature on Power3/Power4
> > AS/400 servers and was contacting IBM customers to sell them black-market
> > activation keys (my cubical happened to share a wall with one of the
> > inventors of the hardware used at the time to confirm the activation
> > keys so I got to hear plenty of details on this).  The DMCA was new at
> > the time and first applied for protecting from DVD copyright, but I have
> > no doubt that if this situation happened today IBM would leverage the
> > DMCA to stop this rather quickly (and honestly, rightly so).
> >
> > The problem is that the DMCA has also been leveraged for cases which are
> > not a direct theft-of-service[12].  I am not saying that IBM will, and I
> > can't expect you to get a committment on that, but you are pushing the
> > risk onto me, the other developers here, and the project as a whole.
> >
> > What am I even talking about, you're probably wondering?  Since IBM is
> > using this feature to protect your intellectual property (AIX licenses,
> > firmware update lockout, etc.) everything about it falls under the
> > purview of the DMCA.  If I find a bug in your open source implementation
> > and report it in a public forum, you could issue a DMCA take-down
> > request.  If I review a code change and conceive of a way it might be
> > used to circumvent your implementation, and I bring it to your
> > attention, you could issue a DMCA take-down request.  If someone comes
> > to us with a 5 year old server and we figure out how to bypass your
> > security lockout so they can flash on the Github version of OpenBMC, you
> > could issue a DMCA take-down request.  If I do a presentation on
> > debugging with dbus and it turns out someone figures out how to use that
> > information to circumvent your licensing feature on the SSH interface,
> > you could issue a DMCA take-down request.
> >
> > These might sound absurd or you might think "IBM would never do that."
> > How do I and the other developers here know?  You're asking us to take
> > on that risk.  And why should I?  I want to stay as far away from
> > anything related to your licensing feature as I possibly can.  It does
> > nothing good for your customers, it does nothing good for this project,
> > and it puts me, a developer, at potential legal risk.
> >
> > While you might have a little bit of code that you're sharing, that
> > maybe other companies can leverage, you are also giving us baggage
> > that reduces our collaboration.  Now, anytime I'm even close to this
> > code, I have to think about not only the technical but now legal
> > ramifications of what I'm doing.  That means, I'm quite likely going to
> > have to just say "do whatever you want and leave me out of it" anytime
> > this code comes up in reviews or discussions.
> >
> > -- References --
> >
> > 1.https://www.acm.org/code-of-ethics
> > 2.https://www.opencompute.org/products#ocp-accepted-inspired-modal
> > 3.https://www.opencompute.org/projects/open-system-firmware
> > 4.https://www.zdnet.com/article/hp-to-begin-charging-for-firmware-updates-and-service-packs-for-servers/
> > 5.https://www.ibm.com/support/pages/management-power8-and-later-update-access-keys#q45
> > 6.https://www.opencompute.org/documents/ibm-white-paper-ownership-and-control-of-firmware-in-open-compute-project-devices
> > 7.https://www.theguardian.com/technology/2021/apr/16/facebook-says-it-has-reached-net-zero-emissions
> > 8.https://www.itrenew.com/resources/the-tco-of-ocp/
> > 9.https://www.gnu.org/philosophy/free-sw.en.html
> > 10.https://en.wikipedia.org/wiki/Tivoization
> > 11.https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act
> > 12.https://www.eff.org/wp/unintended-consequences-16-years-under-dmca
> >

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Brad Bishop]

On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:
>On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
>> Hi Patrick,
>>
>> Re-starting this discussion with the design that is being worked at
>> License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code
>> Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.
>
>I've already written enough on this topic.  You've not added much in
>terms of what I've already written, so I'm not sure what more you want
>me to say.

I just want to say that OEMs have many, many happy customers that gladly 
pay for unlocking things.  They just don't typically hang out here 🙂.  
I just bought a BMC license key the other day for my ~8 year old 
Supermicro x10slh-f.  For what it is worth.  I know a lot of people have 
a problem with charging for security fixes but this is bigger than just 
that.

The legal/DMCA concerns are interesting.  I do wonder if the concerns 
could be generalized to all the code, though, and not just a license 
service.  Licensing features may not be in every OpenBMC users business 
model, but doesn't every business have just as much incentive to go 
after developers for public disclosure of -anything- that could impact 
its business?  What makes the DMCA applicable to a license service only, 
and not, for example, any old security vulnerability in foocorp-ipmi-oem 
or foocorp-misc?

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Patrick Williams]

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

On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:

> So you're going to add some custom PLDM commands to offload this to your
> host firmware.  How is this helpful to the rest of the community?
> Again, why do I want to take on the maintenance risk and legal risk
> associated with this feature?  Why would anyone else in the community?

I had someone ask me offline if this mean that only features that have
applicability to more than one community member would be acceptable.
This was not my intention by saying this.  I was speaking specifically
about *this* feature.

Originally this proposal was that the license server would be a way that
multiple parties could collaborate on it.  Moving it to a custom PLDM
command set diminishes that.

My overall point is that this proposal is, as currently presented and in
my opinion, a net-negative for the project.

In a very general sense, as long as a contribution is going to be
maintained, the contribution follows our processes, and the contribution
isn't considered a bad idea for a variety of maintainer-determined
reasons*, we should be accepting of features that might only be
applicable to one party.  It isn't the wide-spread applicability, or lack
there of, that is an issue.

(*) I'm leaving a lot of wiggle room in that statement because I don't
    want someone to interpret this to mean "Patrick says any code we're
    going to maintain should be acceptable".  It is entirely reasonable
    for maintainers to say: this is not a direction we want to go.  

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Patrick Williams]

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

On Fri, Oct 06, 2023 at 01:17:46PM -0400, Brad Bishop wrote:

> The legal/DMCA concerns are interesting.  I do wonder if the concerns 
> could be generalized to all the code, though, and not just a license 
> service.  Licensing features may not be in every OpenBMC users business 
> model, but doesn't every business have just as much incentive to go 
> after developers for public disclosure of -anything- that could impact 
> its business?  What makes the DMCA applicable to a license service only, 
> and not, for example, any old security vulnerability in foocorp-ipmi-oem 
> or foocorp-misc?

I'm not a lawyer and you'll need to talk to your own legal team for
advice on this matter.

In the broad sense, DMCA was suppose to be about copyright
circumvention (such as what the license server is protecting) but it has
been used in ways greatly beyond that scope.  I previously linked to the
EFF's "Unintended Consequences: 16 years under DMCA" article that
describes many of the ways they feel DMCA has been applied well beyond
that scope.

The Library of Congress publishes all of the exceptions to the DMTF in a
(currently) 15 page regulation[1].  There is generally an exception
documented here for "good-faith security research".  My understanding is
that "any old security vulnerability" would fall under this exception as
long as the security vulnerability isn't primarily used for copyright
circumvention.

Applicable to this discussion is some work the Software Freedom
Conservancy has done[2].  Jailbreaking [some] devices is now a covered
exemption.  It is possible that circumventing license keys in a way that
allows you to run a raw open source image *might* be a DMCA-exempted
activity.  Where it becomes more of a grey area is if the method to
jailbreak would also allow you to install an unpaid copy of the
hypothetical BMC security update images.

[1] https://www.govinfo.gov/content/pkg/FR-2021-10-28/pdf/2021-23311.pdf
[2] https://sfconservancy.org/news/2021/oct/28/2021-DMCA-final-exemptions-win

There are a lot of grey areas here.  To me, the farther we stay away
from licensing and copyright protection the less likely we are to run
afoul of the DMCA.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Andrew Jeffery]

On Fri, 2023-10-06 at 13:17 -0400, Brad Bishop wrote:
> On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:
> > On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
> > > Hi Patrick,
> > > 
> > > Re-starting this discussion with the design that is being worked at
> > > License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code
> > > Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.
> > 
> > I've already written enough on this topic.  You've not added much in
> > terms of what I've already written, so I'm not sure what more you want
> > me to say.
> 
> I just want to say that OEMs have many, many happy customers that gladly 
> pay for unlocking things.  They just don't typically hang out here 🙂.  
> I just bought a BMC license key the other day for my ~8 year old 
> Supermicro x10slh-f.  For what it is worth.  I know a lot of people have 
> a problem with charging for security fixes but this is bigger than just 
> that.
> 

Brad: Given the interest, are you able to provide feedback on IBM's
design proposal?

https://gerrit.openbmc.org/c/openbmc/docs/+/64710

More broadly, setting aside Patrick's legal concerns, I think for this
to go anywhere it has to be demonstrated that there's a group of people
needing a solution and some collective interest in maintaining one. If
we can't get multiple parties to collaborate on a design then I don't
see a reason for trying to maintain it upstream.

From a personal perspective, the concept grinds badly against common
believes and values in open source software projects and I'm not going
to go out of my way to support it. I'm also concerned at the lack of
engagement from IBM on the proposal since reviving the thread. The
concerns raised need responses from the people proposing that a
solution needs to exist. This is a social problem as much as - perhaps
even more so than - a technical one. Both need to be solved together,
and that requires responsive communication and engagement with the
issues raised.

Andrew

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Brad Bishop]

On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>On Fri, 2023-10-06 at 13:17 -0400, Brad Bishop wrote:
>> On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:
>> > On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
>> > > Hi Patrick,
>> > >
>> > > Re-starting this discussion with the design that is being worked at
>> > > License Manager: Add license manager design (Ibd6c6f35) · Gerrit Code
>> > > Review (openbmc.org) <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.
>> >
>> > I've already written enough on this topic.  You've not added much in
>> > terms of what I've already written, so I'm not sure what more you want
>> > me to say.
>>
>> I just want to say that OEMs have many, many happy customers that gladly
>> pay for unlocking things.  They just don't typically hang out here 🙂.
>> I just bought a BMC license key the other day for my ~8 year old
>> Supermicro x10slh-f.  For what it is worth.  I know a lot of people have
>> a problem with charging for security fixes but this is bigger than just
>> that.
>>
>
>Brad: Given the interest, are you able to provide feedback on IBM's
>design proposal?
>
>https://gerrit.openbmc.org/c/openbmc/docs/+/64710

Hah - that's what I get for opening my mouth 🤣.  I wouldn't say I'm 
interested.  I'm not sure why I felt compelled to respond - Maybe I was 
just feeling chatty and wanted to support one of my fellow server OEMs.

Anyhow, I took a quick look and in general the proposal seems lacking in 
details.  References to dbus objects and interfaces need to be filled in 
with details.  "License data" needs to be explained - what is it, in 
terms of Redfish and DBus?  Other vague statements about Redfish need to 
be explained in specific terms of the new schema (resources, actions, 
etc). Interactions between applications need to be spelled out 
explicitly (more dbus interfaces?).  The resulting Redfish data model is 
not apparent to me (I admit I've never looked at the new schema, but I 
do know a thing or two about Redfish so ideally I shouldn't need to?).  
Much like the Redfish concern, the PLDM data model needs to be expanded 
upon and explained in terms of a PLDM specification.

>More broadly, setting aside Patrick's legal concerns,

And they do seem like reasonable concerns, but I am not a lawyer.  I 
don't think engineers are going to be able to allay those concerns. 

>I think for this
>to go anywhere it has to be demonstrated that there's a group of people
>needing a solution 

Isn't this self-evident from the schema being adopted by the DMTF?

>and some collective interest in maintaining one. If
>we can't get multiple parties to collaborate on a design then I don't
>see a reason for trying to maintain it upstream.

How many parties collaborated on getting FSI into Linux?   How many 
parties are collaborating on <foocorp>-misc or <platform>-misc?  Are 
those different somehow?

>From a personal perspective, the concept grinds badly against common
>believes and values in open source software projects and I'm not going
>to go out of my way to support it. 

I'm sure it probably sounds like I'm advocating for this feature.  I'm 
really not.  I'm trying to generally improve my understanding of what 
types of code submissions are welcome and what kinds are not through 
questions.  Maybe I just need to stop looking for patterns where none 
exist...

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 13-10-2023 09:43, Brad Bishop wrote:
> On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>> On Fri, 2023-10-06 at 13:17 -0400, Brad Bishop wrote:
>>> On Fri, Oct 06, 2023 at 07:29:27AM -0500, Patrick Williams wrote:
>>> > On Fri, Oct 06, 2023 at 10:21:01AM +0530, Sunitha Harish wrote:
>>> > > Hi Patrick,
>>> > >
>>> > > Re-starting this discussion with the design that is being worked at
>>> > > License Manager: Add license manager design (Ibd6c6f35) · Gerrit 
>>> Code
>>> > > Review (openbmc.org) 
>>> <https://gerrit.openbmc.org/c/openbmc/docs/+/64710>.
>>> >
>>> > I've already written enough on this topic.  You've not added much in
>>> > terms of what I've already written, so I'm not sure what more you 
>>> want
>>> > me to say.
>>>
>>> I just want to say that OEMs have many, many happy customers that 
>>> gladly
>>> pay for unlocking things.  They just don't typically hang out here 🙂.
>>> I just bought a BMC license key the other day for my ~8 year old
>>> Supermicro x10slh-f.  For what it is worth.  I know a lot of people 
>>> have
>>> a problem with charging for security fixes but this is bigger than just
>>> that.
>>>
>>
>> Brad: Given the interest, are you able to provide feedback on IBM's
>> design proposal?
>>
>> https://gerrit.openbmc.org/c/openbmc/docs/+/64710
>
> Hah - that's what I get for opening my mouth 🤣.  I wouldn't say I'm 
> interested.  I'm not sure why I felt compelled to respond - Maybe I 
> was just feeling chatty and wanted to support one of my fellow server 
> OEMs.
>
> Anyhow, I took a quick look and in general the proposal seems lacking 
> in details.  References to dbus objects and interfaces need to be 
> filled in with details.  "License data" needs to be explained - what 
> is it, in terms of Redfish and DBus?  Other vague statements about 
> Redfish need to be explained in specific terms of the new schema 
> (resources, actions, etc). Interactions between applications need to 
> be spelled out explicitly (more dbus interfaces?).  The resulting 
> Redfish data model is not apparent to me (I admit I've never looked at 
> the new schema, but I do know a thing or two about Redfish so ideally 
> I shouldn't need to?).  Much like the Redfish concern, the PLDM data 
> model needs to be expanded upon and explained in terms of a PLDM 
> specification.

Thank you Brad & Andrew, we will address your feedback and update the 
design document accordingly.

>
>> More broadly, setting aside Patrick's legal concerns,
>
> And they do seem like reasonable concerns, but I am not a lawyer. I 
> don't think engineers are going to be able to allay those concerns.
Yes. Based on Patrick's concerns - is it still a legal concern if BMC 
works as a mediator to forward the license to the host, without 
processing or installing the license at BMC? Host is not an OpenSource 
code, and any OEMs can do their proprietary implementations as needed.
>> I think for this
>> to go anywhere it has to be demonstrated that there's a group of people
>> needing a solution 
>
> Isn't this self-evident from the schema being adopted by the DMTF?
>
+1
>> and some collective interest in maintaining one. If
>> we can't get multiple parties to collaborate on a design then I don't
>> see a reason for trying to maintain it upstream.
>
> How many parties collaborated on getting FSI into Linux?   How many 
> parties are collaborating on <foocorp>-misc or <platform>-misc?  Are 
> those different somehow?
>
We are looking forward for the collaboration from the community on this 
feature.
>> From a personal perspective, the concept grinds badly against common
>> believes and values in open source software projects and I'm not going
>> to go out of my way to support it. 
>
> I'm sure it probably sounds like I'm advocating for this feature. I'm 
> really not.  I'm trying to generally improve my understanding of what 
> types of code submissions are welcome and what kinds are not through 
> questions.  Maybe I just need to stop looking for patterns where none 
> exist...

Thank you Brad for your views. Please continue.

If there are any technical concern about this feature, we will work on 
that as per the comments received on the design document. Legal concern 
can be resolved by finding out a way forward together as a community.

Thanks & regards,
Sunitha

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Andrew Jeffery]

On Fri, 2023-10-13 at 00:13 -0400, Brad Bishop wrote:
> On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
> 
> > I think for this
> > to go anywhere it has to be demonstrated that there's a group of people
> > needing a solution 
> 
> Isn't this self-evident from the schema being adopted by the DMTF?

My comment was more in the context of OpenBMC and less in the context
of the DMTF. Standards that the DMTF produce are more broadly
applicable than to OpenBMC, so not all interested parties pushing it in
the DMTF are going to be parties willing to do the social legwork to
gain acceptance for and to maintain an implementation in OpenBMC.

> 
> > and some collective interest in maintaining one. If
> > we can't get multiple parties to collaborate on a design then I don't
> > see a reason for trying to maintain it upstream.
> 
> How many parties collaborated on getting FSI into Linux?   How many 
> parties are collaborating on <foocorp>-misc or <platform>-misc?  Are 
> those different somehow?

How do FSI, <foocorp>-misc or <platform>-misc run afoul of common open
source beliefs and values? FSI is a specification and implementation of
a communication bus for processor management and doesn't particularly
interfere with any open source ideological principles. Implementing a
subsystem for it in upstream Linux doesn't impact anyone's ability to
run, study, share or modify the software on their system.

What we're discussing here is a community-endorsed implementation of a
license server that exists to constrain people's abilities to run,
study, share or modify the software or hardware that composes their
machine. That certainly isn't supporting the principles on which open
source software collaboration is often built.

I'm asking for a higher bar to establish whether a license server
implementation that constrains user freedoms is something the OpenBMC
community significantly values. Satisfying that (in my mind) requires a
diverse set of community members come forward and demonstrate that
they're willing to collaborate on design and maintenance, as a proxy
for value.

However, there is an escape hatch for project social issues. For
example interested parties might choose to collaborate on the license
manager implementation outside of the OpenBMC org, and package it
through Yocto or OpenEmbedded.


Andrew

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Brad Bishop]

On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>On Fri, 2023-10-13 at 00:13 -0400, Brad Bishop wrote:
>> On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>>
>> > I think for this
>> > to go anywhere it has to be demonstrated that there's a group of people
>> > needing a solution
>>
>> Isn't this self-evident from the schema being adopted by the DMTF?
>
>My comment was more in the context of OpenBMC and less in the context
>of the DMTF. Standards that the DMTF produce are more broadly
>applicable than to OpenBMC, so not all interested parties pushing it in
>the DMTF are going to be parties willing to do the social legwork to
>gain acceptance for and to maintain an implementation in OpenBMC.

Makes sense.

>> > and some collective interest in maintaining one. If
>> > we can't get multiple parties to collaborate on a design then I don't
>> > see a reason for trying to maintain it upstream.
>>
>> How many parties collaborated on getting FSI into Linux?   How many
>> parties are collaborating on <foocorp>-misc or <platform>-misc?  Are
>> those different somehow?
>
>How do FSI, <foocorp>-misc or <platform>-misc run afoul of common open
>source beliefs and values? 

Obviously they don't.  I asked this only in response to the comment 
about a lack of collaboration from multiple parties as rationale for 
exluding something.  It sounds like that is a red-herring.

>I'm asking for a higher bar to establish whether a license server
>implementation that constrains user freedoms is something the OpenBMC
>community significantly values. Satisfying that (in my mind) requires a
>diverse set of community members come forward and demonstrate that
>they're willing to collaborate on design and maintenance, as a proxy
>for value.

Fair enough.

>However, there is an escape hatch for project social issues. For
>example interested parties might choose to collaborate on the license
>manager implementation outside of the OpenBMC org, and package it
>through Yocto or OpenEmbedded.

I've been thinking along similar lines lately and I like this idea.  For 
a license server and even in general I think less centralized control 
and less tightly coupled software would be a good direction to take.

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 13-10-2023 21:33, Brad Bishop wrote:
> On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>> On Fri, 2023-10-13 at 00:13 -0400, Brad Bishop wrote:
>>> On Fri, Oct 13, 2023 at 12:32:09PM +1030, Andrew Jeffery wrote:
>>>
>>> > I think for this
>>> > to go anywhere it has to be demonstrated that there's a group of 
>>> people
>>> > needing a solution
>>>
>>> Isn't this self-evident from the schema being adopted by the DMTF?
>>
>> My comment was more in the context of OpenBMC and less in the context
>> of the DMTF. Standards that the DMTF produce are more broadly
>> applicable than to OpenBMC, so not all interested parties pushing it in
>> the DMTF are going to be parties willing to do the social legwork to
>> gain acceptance for and to maintain an implementation in OpenBMC.
>
> Makes sense.
>
>>> > and some collective interest in maintaining one. If
>>> > we can't get multiple parties to collaborate on a design then I don't
>>> > see a reason for trying to maintain it upstream.
>>>
>>> How many parties collaborated on getting FSI into Linux?   How many
>>> parties are collaborating on <foocorp>-misc or <platform>-misc?  Are
>>> those different somehow?
>>
>> How do FSI, <foocorp>-misc or <platform>-misc run afoul of common open
>> source beliefs and values? 
>
> Obviously they don't.  I asked this only in response to the comment 
> about a lack of collaboration from multiple parties as rationale for 
> exluding something.  It sounds like that is a red-herring.
>
>> I'm asking for a higher bar to establish whether a license server
>> implementation that constrains user freedoms is something the OpenBMC
>> community significantly values. Satisfying that (in my mind) requires a
>> diverse set of community members come forward and demonstrate that
>> they're willing to collaborate on design and maintenance, as a proxy
>> for value.
>
> Fair enough.
>
Intention is not to implement a license server at BMC. The idea is to 
just add support for the user interfaces via BMC, which can help routing 
the licenses to the host sitting on top of the firmware. I will start a 
discord message on this - to look for more community interest.
>> However, there is an escape hatch for project social issues. For
>> example interested parties might choose to collaborate on the license
>> manager implementation outside of the OpenBMC org, and package it
>> through Yocto or OpenEmbedded.
>
> I've been thinking along similar lines lately and I like this idea.  
> For a license server and even in general I think less centralized 
> control and less tightly coupled software would be a good direction to 
> take.
I am not very clear about this. The control and processing of the 
license will not be in BMC scope. The host should manage it.

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Brad Bishop]

On Wed, Oct 18, 2023 at 12:51:47PM +0530, Sunitha Harish wrote:
>
>On 13-10-2023 21:33, Brad Bishop wrote:
>>On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>>>However, there is an escape hatch for project social issues. For
>>>example interested parties might choose to collaborate on the license
>>>manager implementation outside of the OpenBMC org, and package it
>>>through Yocto or OpenEmbedded.
>>
>>I've been thinking along similar lines lately and I like this idea.  
>>For a license server and even in general I think less centralized 
>>control and less tightly coupled software would be a good direction 
>>to take.
>I am not very clear about this. The control and processing of the 
>license will not be in BMC scope. The host should manage it.

The suggestion here is to:

1 - write your license server application
2 - throw it up on Github somewhere other than openbmc
3 - submit a recipe to meta-oe

It's possible the meta-oe maintainers could reject your recipe for the 
same reasons as you've been rejected here (or any other variety of 
reasons).  In that case you could just make a meta layer with a single 
recipe and throw that up on github too.

The downside to this approach is you shouldn't use projects like 
phosphor-logging, sdbusplus, or phosphor-dbus-interfaces or any other 
recipes that are provided by OpenBMC or in meta-phosphor.  Certainly not 
if you want to get a recipe into meta-oe.

IMO this isn't necessarily a bad thing, though.  This is what I meant by 
tightly coupled software - if you take this approach and avoid OpenBMC 
specific frameworks...who knows - if you make a an really awesome, 
useful piece of software - you might even get collaborators from outside 
OpenBMC.

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 18-10-2023 18:48, Brad Bishop wrote:
> On Wed, Oct 18, 2023 at 12:51:47PM +0530, Sunitha Harish wrote:
>>
>> On 13-10-2023 21:33, Brad Bishop wrote:
>>> On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>>>> However, there is an escape hatch for project social issues. For
>>>> example interested parties might choose to collaborate on the license
>>>> manager implementation outside of the OpenBMC org, and package it
>>>> through Yocto or OpenEmbedded.
>>>
>>> I've been thinking along similar lines lately and I like this idea.  
>>> For a license server and even in general I think less centralized 
>>> control and less tightly coupled software would be a good direction 
>>> to take.
>> I am not very clear about this. The control and processing of the 
>> license will not be in BMC scope. The host should manage it.
>
> The suggestion here is to:
>
> 1 - write your license server application
> 2 - throw it up on Github somewhere other than openbmc
> 3 - submit a recipe to meta-oe
>
Thank you for clarifying.
> It's possible the meta-oe maintainers could reject your recipe for the 
> same reasons as you've been rejected here (or any other variety of 
> reasons).  In that case you could just make a meta layer with a single 
> recipe and throw that up on github too.
>
> The downside to this approach is you shouldn't use projects like 
> phosphor-logging, sdbusplus, or phosphor-dbus-interfaces or any other 
> recipes that are provided by OpenBMC or in meta-phosphor. Certainly 
> not if you want to get a recipe into meta-oe. 

I think this would defeat the purpose of this proposal. We want to use 
the BMC as a pass through entity for the licenses. It should be handling 
the redfish commands (bmcweb) on LicenseService schema - which is 
tightly coupled with the dbus. And the communication to the host at our 
server is via PLDM/MCTP. So we can not exclude the openbmc components. 
More over this new meta-oe work will turn out to be costly.

@Ed/@Gunnar, are you interested in supporting the LicenseService schema 
at bmcweb?

> IMO this isn't necessarily a bad thing, though.  This is what I meant 
> by tightly coupled software - if you take this approach and avoid 
> OpenBMC specific frameworks...who knows - if you make a an really 
> awesome, useful piece of software - you might even get collaborators 
> from outside OpenBMC.

If the app which is planned now is processing/validating the licenses, 
then it would turn out to be an awesome piece of software. But that is 
not the intention. Lately, as per Andrew J and Manoj's review comments - 
the design is taking a direction where the objects will be hosted at 
PLDM itself and there is no need of a new application called LicenseManager.

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

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


On 19-10-2023 15:56, Sunitha Harish wrote:
>
> On 18-10-2023 18:48, Brad Bishop wrote:
>> On Wed, Oct 18, 2023 at 12:51:47PM +0530, Sunitha Harish wrote:
>>>
>>> On 13-10-2023 21:33, Brad Bishop wrote:
>>>> On Fri, Oct 13, 2023 at 05:04:23PM +1030, Andrew Jeffery wrote:
>>>>> However, there is an escape hatch for project social issues. For
>>>>> example interested parties might choose to collaborate on the license
>>>>> manager implementation outside of the OpenBMC org, and package it
>>>>> through Yocto or OpenEmbedded.
>>>>
>>>> I've been thinking along similar lines lately and I like this 
>>>> idea.  For a license server and even in general I think less 
>>>> centralized control and less tightly coupled software would be a 
>>>> good direction to take.
>>> I am not very clear about this. The control and processing of the 
>>> license will not be in BMC scope. The host should manage it.
>>
>> The suggestion here is to:
>>
>> 1 - write your license server application
>> 2 - throw it up on Github somewhere other than openbmc
>> 3 - submit a recipe to meta-oe
>>
> Thank you for clarifying.
>> It's possible the meta-oe maintainers could reject your recipe for 
>> the same reasons as you've been rejected here (or any other variety 
>> of reasons).  In that case you could just make a meta layer with a 
>> single recipe and throw that up on github too.
>>
>> The downside to this approach is you shouldn't use projects like 
>> phosphor-logging, sdbusplus, or phosphor-dbus-interfaces or any other 
>> recipes that are provided by OpenBMC or in meta-phosphor. Certainly 
>> not if you want to get a recipe into meta-oe. 
>
> I think this would defeat the purpose of this proposal. We want to use 
> the BMC as a pass through entity for the licenses. It should be 
> handling the redfish commands (bmcweb) on LicenseService schema - 
> which is tightly coupled with the dbus. And the communication to the 
> host at our server is via PLDM/MCTP. So we can not exclude the openbmc 
> components. More over this new meta-oe work will turn out to be costly.
>
> @Ed/@Gunnar, are you interested in supporting the LicenseService 
> schema at bmcweb?
>
I see an old bmcweb commit - abandoned here Adding Support for License 
Service (I5c3625a9) · Gerrit Code Review (openbmc.org) 
<https://gerrit.openbmc.org/c/openbmc/bmcweb/+/54037> after some initial 
reviews from Ed. Seems like Intel/AMI had some features consuming the 
LicenseService?
>> IMO this isn't necessarily a bad thing, though.  This is what I meant 
>> by tightly coupled software - if you take this approach and avoid 
>> OpenBMC specific frameworks...who knows - if you make a an really 
>> awesome, useful piece of software - you might even get collaborators 
>> from outside OpenBMC.
>
> If the app which is planned now is processing/validating the licenses, 
> then it would turn out to be an awesome piece of software. But that is 
> not the intention. Lately, as per Andrew J and Manoj's review comments 
> - the design is taking a direction where the objects will be hosted at 
> PLDM itself and there is no need of a new application called 
> LicenseManager.
>
>

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

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Andrew Jeffery]

On Thu, 2023-10-19 at 15:56 +0530, Sunitha Harish wrote:
> 
> More over this new meta-oe work will turn out to be costly.

It's a bit of a tangent, but I have to ask: What's the basis for the
assertion that adding a recipe to meta-openembedded or some other
upstream layer will be costly? That's not at all my experience or
expectation.

Andrew

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Sunitha Harish]

On 20-10-2023 10:36, Andrew Jeffery wrote:
> On Thu, 2023-10-19 at 15:56 +0530, Sunitha Harish wrote:
>> More over this new meta-oe work will turn out to be costly.
> It's a bit of a tangent, but I have to ask: What's the basis for the
> assertion that adding a recipe to meta-openembedded or some other
> upstream layer will be costly? That's not at all my experience or
> expectation.
>
> Andrew
We are not planning to have a license SERVER at BMC, which will 
interpret and process the licenses. There is no usecase for us to do one 
in near future as well. Only need is to add a way at BMC which can 
enable user to upload the license by implementing the LicenseService 
schemas. Considering that, i mentioned that this will be costly for me.

Re: D-bus model proposal for pay for access features - LicenseService at OpenBMC

[Abhilash Kollam]

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

By upstreaming license-related code, I believe what we are trying is to
have a frequent rebase with the upstream code base. Right now we cannot
rebase the PLDM code because of it.  Can we separate the PLDM model for
license from main PLDM code base? Can we have redfish implementation for
License in bmcweb and upstream? If we can do both then we can keep the
majority of license-related code downstream. It does not hamper our
rebasing effort as well.

Please correct me if I am wrong.

On Fri, Oct 20, 2023 at 11:12 AM Sunitha Harish <sunithaharish04@gmail.com>
wrote:

>
> On 20-10-2023 10:36, Andrew Jeffery wrote:
> > On Thu, 2023-10-19 at 15:56 +0530, Sunitha Harish wrote:
> >> More over this new meta-oe work will turn out to be costly.
> > It's a bit of a tangent, but I have to ask: What's the basis for the
> > assertion that adding a recipe to meta-openembedded or some other
> > upstream layer will be costly? That's not at all my experience or
> > expectation.
> >
> > Andrew
> We are not planning to have a license SERVER at BMC, which will
> interpret and process the licenses. There is no usecase for us to do one
> in near future as well. Only need is to add a way at BMC which can
> enable user to upload the license by implementing the LicenseService
> schemas. Considering that, i mentioned that this will be costly for me.
>

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