* Secure boot/signed images and GPL code @ 2020-11-03 17:20 Deepak Kodihalli 2020-11-03 20:56 ` Patrick Williams 0 siblings, 1 reply; 7+ messages in thread From: Deepak Kodihalli @ 2020-11-03 17:20 UTC (permalink / raw) To: openbmc, cjengel, joel, joseph-reynolds [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-03 17:20 Secure boot/signed images and GPL code Deepak Kodihalli @ 2020-11-03 20:56 ` Patrick Williams 2020-11-03 21:21 ` Lee Fisher ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Patrick Williams @ 2020-11-03 20:56 UTC (permalink / raw) To: Deepak Kodihalli; +Cc: cjengel, openbmc, joseph-reynolds [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-03 20:56 ` Patrick Williams @ 2020-11-03 21:21 ` Lee Fisher 2020-11-04 13:31 ` Patrick Williams 2020-11-03 22:59 ` Doman, Jonathan 2020-11-06 17:19 ` Vernon Mauery 2 siblings, 1 reply; 7+ messages in thread From: Lee Fisher @ 2020-11-03 21:21 UTC (permalink / raw) To: openbmc > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-03 21:21 ` Lee Fisher @ 2020-11-04 13:31 ` Patrick Williams 0 siblings, 0 replies; 7+ messages in thread From: Patrick Williams @ 2020-11-04 13:31 UTC (permalink / raw) To: Lee Fisher; +Cc: openbmc [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-03 20:56 ` Patrick Williams 2020-11-03 21:21 ` Lee Fisher @ 2020-11-03 22:59 ` Doman, Jonathan 2020-11-06 17:19 ` Vernon Mauery 2 siblings, 0 replies; 7+ messages in thread From: Doman, Jonathan @ 2020-11-03 22:59 UTC (permalink / raw) To: patrick, deepak.kodihalli.83; +Cc: cjengel, openbmc, joseph-reynolds (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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-03 20:56 ` Patrick Williams 2020-11-03 21:21 ` Lee Fisher 2020-11-03 22:59 ` Doman, Jonathan @ 2020-11-06 17:19 ` Vernon Mauery 2020-11-06 21:24 ` Joseph Reynolds 2 siblings, 1 reply; 7+ messages in thread From: Vernon Mauery @ 2020-11-06 17:19 UTC (permalink / raw) To: Patrick Williams; +Cc: cjengel, openbmc, Deepak Kodihalli, joseph-reynolds 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Secure boot/signed images and GPL code 2020-11-06 17:19 ` Vernon Mauery @ 2020-11-06 21:24 ` Joseph Reynolds 0 siblings, 0 replies; 7+ messages in thread From: Joseph Reynolds @ 2020-11-06 21:24 UTC (permalink / raw) To: Vernon Mauery, Patrick Williams Cc: cjengel, openbmc, Deepak Kodihalli, 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-11-06 21:25 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-03 17:20 Secure boot/signed images and GPL code Deepak Kodihalli 2020-11-03 20:56 ` Patrick Williams 2020-11-03 21:21 ` Lee Fisher 2020-11-04 13:31 ` Patrick Williams 2020-11-03 22:59 ` Doman, Jonathan 2020-11-06 17:19 ` Vernon Mauery 2020-11-06 21:24 ` Joseph Reynolds
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).