Secure boot/signed images and GPL code

Secure boot/signed images and GPL code

[Deepak Kodihalli]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

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).

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?
- Do you (or your legal team) view this is only a GPLv3 problem, or not a
problem at all?

Thanks,
Deepak

[-- Attachment #2: Type: text/html, Size: 1283 bytes --]

Re: Secure boot/signed images and GPL code

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 5299 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Secure boot/signed images and GPL code

[Lee Fisher]

> 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? [...]

In this thread I don't see any reference to OpenBMC use of the existing
Shim[1] -- the current Linux UEFI Secure Boot solution to address these
legal issues. It seems that if the Shim can't work for OpenBMC case,
then OpenBMC could create a similar Shim-like widget. FYI, there's a
Shim mailing list.

[1] https://github.com/rhboot/shim

https://lists.freedesktop.org/mailman/listinfo/shim-review

Re: Secure boot/signed images and GPL code

[Doman, Jonathan]

(Also not a lawyer and not speaking for my employer.)

On Tue, 2020-11-03 at 14:56 -0600, Patrick Williams wrote:
> 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.

According to one analysis [1] of the GPL, this desire to keep
enterprise systems locked down is why v3 contains language defining
"User Products". If your device is not a User Product ("for personal,
family, or household purposes" or "for incorporation into a dwelling"),
then you are not obligated to provide Installation Information
containing signing keys (or whatever information might be needed).

1: https://copyleft.org/guide/comprehensive-gpl-guidech10.html#x13-850009.9.2

Re: Secure boot/signed images and GPL code

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Tue, Nov 03, 2020 at 01:21:53PM -0800, Lee Fisher wrote:
> In this thread I don't see any reference to OpenBMC use of the existing
> Shim[1] -- the current Linux UEFI Secure Boot solution to address these
> legal issues. It seems that if the Shim can't work for OpenBMC case,
> then OpenBMC could create a similar Shim-like widget. FYI, there's a
> Shim mailing list.

The class of chips typically used for OpenBMC don't currently support
UEFI but instead use u-boot as the early initialization + boot loader.
u-boot has a concept of "Secondary Program Loader" (SPL) which can allow
a key indirection in a similar way to the UEFI shim.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Secure boot/signed images and GPL code

[Vernon Mauery]

On 03-Nov-2020 02:56 PM, Patrick Williams wrote:
>
>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.

You are right, the AST2600 OTP leaves something to be desired. If all 
the key regions are not initially programmed, it is possible to program 
a new key, deprecate all the old keys, and take control of the system. 
But programming all the keys prevents transferring the system from one 
owner to another (where the owner is the one providing firmware).

Storing and provisioning keys is hardest part of any crypto system. If 
we have ideas on how to make the AST2700 better, Aspeed has engineers on 
this list and would probably like to hear any great ideas.

--Vernon

Re: Secure boot/signed images and GPL code

[Joseph Reynolds]

On 11/6/20 11:19 AM, Vernon Mauery wrote:
> On 03-Nov-2020 02:56 PM, Patrick Williams wrote:
>>
>> 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.
>
> You are right, the AST2600 OTP leaves something to be desired. If all 
> the key regions are not initially programmed, it is possible to 
> program a new key, deprecate all the old keys, and take control of the 
> system. But programming all the keys prevents transferring the system 
> from one owner to another (where the owner is the one providing 
> firmware).
>
> Storing and provisioning keys is hardest part of any crypto system. If 
> we have ideas on how to make the AST2700 better, Aspeed has engineers 
> on this list and would probably like to hear any great ideas.

The OCP (Open Compute Project) Security Project has ongoing discussions 
on similar topics including secure transfer of ownership, secure boot, 
and secure recovery.

I don't have more details because it's not my technical area.  The wiki 
has links to OCP Security goals, papers, and their meetings.
https://www.opencompute.org/wiki/Security

- Joseph

>
> --Vernon
>