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

[Patrick Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20231006/8e6bf2d7/attachment-0001.sig>