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 at gmail.com> wrote:
>>
>> Hi All,
>>
>> I would like to introduce a dbus model proposal around pay for access features.Normally IBM system ships with more hardware than was purchased, which can be unlocked later.
>
>It would be great to get a lot more background here.  
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