D-bus model proposal for pay for access features
Patrick Williams
patrick at stwcx.xyz
Thu May 6 03:36:20 AEST 2021
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/20210505/24f33e42/attachment.sig>
More information about the openbmc
mailing list