Secure boot/signed images and GPL code

[Patrick Williams]

I'm not a lawyer and I don't speak for the legal team of my employer in
any way here nor should this be taken as legal advice...

On Tue, Nov 03, 2020 at 10:50:07PM +0530, Deepak Kodihalli wrote:
> Hi,
> 
> Does secure boot on the BMC (I think for my question it doesn't matter
> where the hardware root of trust is - it could be on the BMC or an external
> chip) or signed images deprive users of rights associated with code in
> OpenBMC that is GPL licensed? Meaning, GPL allows users to modify and
> distribute the GPL components. I'm not a legal expert, but I understand
> from the legal team in my company that these rights are not limited to
> making modifications to the GPL code and that they also imply being able to
> deploy/boot such modified code; and the problem is secure boot/signed
> images would prevent the same. It also looks like this isn't specific to
> GPLv3, but GPL in general (for eg GPLv2 clause 6).

My reading and understanding of GPLv2 does not suggest there is any
right to *run* the code; only that the source is available.  This was a
big debate about 15 years ago around Tivo[1].  What they were doing was
against the spirit of what Stallman intended with GNU, but wasn't
against the letter of the license.  The response was GPLv3 with better
language.

I've re-read GPLv2 Clause 6 and I'm not sure how someone could derive a
requirement to publish keys or disable key verification as a result.
I think the relevant part here is "You may not impose any further
restrictions on the recipients' exercise of the rights granted herein",
but you need to answer what rights are these?  Throughout the GPLv2 the
rights are { copy, distribute, modify }.  You can modify a digitally
signed image all you want; it just won't work anymore.  This is the
letter verses spirit.  The intent was clearly(?) "modify *and run*" but
the language wasn't precise as such.

If FSF/GNU thought they had a legal standing here, I think they would
have went after Tivo and others years ago.  They didn't and instead
wrote GPLv3.

Most of our software uses the Apache license which does not prevent
Tivoization like GPLv3 might.  I haven't done an analysis lately but I
wonder if we have any packages at all that are GPLv3-only in the default
image.  Does anyone care enough that we should work to remove them
and/or prohibit future ones?  Yocto has a pretty straight-forward way to
error out on certain licenses.

> How are others dealing with this:
> - By having an ability to disable secure boot (I see this as optional in
> https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/26169/)? What if this
> is not an option on a system?
> - Other options?

In the context of a server, I don't think most companies would want a
way to disable secure boot.  It does provide fairly important protection
to the integrity of the server.  But, it is valuable to many customers
to have a method to transition the trusted signing keys from one entity
to another.

A few examples from our use cases:

    - We make customizations to our firmware that are specific to our
      deployment processes and are not relevant to other environments.
      We want a method to bundle those customizations into our own
      images and an OEM/ODM might not have access to those
      customizations.

    - We trust our own signing mechanism and not the OEM/ODMs.  At
      another company, I personally witnessed an ODM that had production
      secureboot signing keys on developer laptops and those keys were
      also used to sign debug images.  Either the keys or the debug
      images could have escaped that ODM and could be used to compromise
      our servers.

    - When we remove a server from our datacenter we want it to be
      recycled.  This means we need to transition the keys away from our
      own keys and into a state where either the recycler's or
      end-user's keys can become the trusted authority.  Without this,
      the server is a paperweight. 

    - There have been security vulnerabilities in software packages used
      by OpenBMC (ex. SSL, systemd to pick on a few) but the OEM who
      originally supplied the firmware may no longer support updates for
      the server, or may not deliver those updates in a timely manner
      relative to the CVE release.  There should be a mechanism for the
      end-user to deploy security fixes without the OEM's involvement.

In the doc you pointed to, I asked how key transition works, but the
doc hasn't been updated to better describe it yet[2].  The initial
response makes it seem like the AST2600 OTP doesn't give a whole lot of
capabilities here, which is fairly concerning.  I know there are some
design proposals that use a secondary device to assist with
secureboot[3,4,5] which might better handle key transition.

1. https://en.wikipedia.org/wiki/Tivoization
2. https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/26169/2/security/OpenBMCSecureBoot.md#93
3. https://opentitan.org/
4. https://github.com/opencomputeproject/Project_Olympus/tree/master/Project_Cerberus
5. https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/firmware-resilience-blocks-solution-brief.pdf

-- 
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/20201103/a1ff6896/attachment.sig>