D-bus model proposal for pay for access features
bradleyb at fuzziesquirrel.com
Wed May 5 09:38:43 AEST 2021
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.
>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...
>that, if done wrong, could be very harmful to the goals of the
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
In our system design, the BMC is not doing the actual license
verification. It is only a proxy, providing an interface to a user
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
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
>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
>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
>How does this affect our standing in things like OCP open system
I wouldn't expect this to affect our standing in OCP in any way.
>Does this OpenBMC systems that enable this feature
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
thx - brad
More information about the openbmc