[Ksummit-discuss] [TECH TOPIC] Firmware signing

[Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Patches are in the works for the provision of signatures for firmware blobs
for the kernel to check, thus allowing the kernel to act as gatekeeper on what
firmware blobs get loaded where.

Note that it has been agreed that signatures will be in separate files to the
firmware blobs so as not to potentially corrupt a blob by copying it to an OS
that doesn't expect the signature.  Also, we don't want to modify the blob in
case of IP.

We're currently using PKCS#7/CMS messages as the signature format since we
have a PKCS#7 parser and verifier already in the kernel for kexec.

Patches have been proposed for inclusion in security/next that allow PKCS#11
to be used to supply h/w keys to the sign-file program and to the kernel build
process.

There are a number of areas that could do with sorting out with regard key
policy:

 (1) Should signatures produced by the manager of the linux-firmware package
     be allowed only?

 (2) If the linux-firmware packages are signed by a single key (or just a few
     keys) it may be manageable to compile all these keys into the kernel.

 (3) If the vendors of firmware blobs supply signatures, should we accept
     those instead of or as well as linux-firmware signatures?

 (4) If we start taking vendor created blobs, what do we do with all the
     vendor keys?  Compiling them into the kernel could quickly get out of
     hand and asking the user to add them to the UEFI keystore has the
     potential to brick the user's system due to a dodgy BIOS.

 (5) For firmware signatures, the patches we have currently expect to find a
     signed attribute in the PKCS#7 that specifies the same name as is passed
     to request_firmware().

 (6) Should module signatures contain the module name - to be matched against
     the modinfo structure after the signature is checked?

 (7) Do we want to have the driver mandate the key that will be used when
     requesting firmware?  How would we specify the key?  I'm loathe to
     include a hash of the public key since that means the driver is then tied
     to a particular key.

 (8) Can we then trust that key if we load it on the basis that a driver
     specifies it by public key hash, even it we can't chain back from it to
     the system_trusted_keyring.

 (9) Do we allow UEFI blacklisting of firmware signatures?

Some points that may be of use in considering the above:

 (A) PKCS#7/CMS messages can take multiple signatures.  Extra signatures can
     be added at a later date.

 (B) We can load keys dynamically - provided we can verify them with a key we
     already have.

 (C) If we can't trace a key back to a key we know we trust, that key cannot
     be used.

 (D) The PKCS#7/CMS field that matches the signing key is not itself signed.

If we do have this discussion, it would be useful to have some or all of Luis
Rodriguez, David Woodhouse, Andy Lutomirski, Kyle McMartin, Seth Forshee and
Mimi Zohar present.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
> 
>  (1) Should signatures produced by the manager of the linux-firmware package
>      be allowed only?
> 
>  (2) If the linux-firmware packages are signed by a single key (or just a few
>      keys) it may be manageable to compile all these keys into the kernel.

I really think we want to allow firmware to be signed by the vendor who
created it — and we want the linux-firmware.git repository to carry the
original vendors' signatures along with the firmware blobs.

Having a signature generated by the linux-firmware packager which just
certifies that this *is* the blob that was in the linux-firmware.git
repository is only a partial solution.

I think we probably want to extend the request_firmware() call to
optionally take an additional certificate identifier (or hash), and
require the firmware to be signed with *that* certificate.

Rather than building the full cert into the kernel, perhaps we'd only
put the *hash* into the kernel, and require the PKCS#7 signature to
*include* the signing cert.

So, for example, the iwlwifi driver could provide a hash of Intel's
firmware-signing cert. And the firmware would come with a detached
PKCS#7 signature *containing* that signing cert, for validation to
succeed.

In the case where the kernel has been built to require signed firmware
and a driver *doesn't* specify the acceptable signing cert, *then* a
system-wide trusted certificate should be accepted.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
> Patches are in the works for the provision of signatures for firmware blobs
> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> firmware blobs get loaded where.
> 
> Note that it has been agreed that signatures will be in separate files to the
> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> that doesn't expect the signature.  Also, we don't want to modify the blob in
> case of IP.
> 
> We're currently using PKCS#7/CMS messages as the signature format since we
> have a PKCS#7 parser and verifier already in the kernel for kexec.
> 
> Patches have been proposed for inclusion in security/next that allow PKCS#11
> to be used to supply h/w keys to the sign-file program and to the kernel build
> process.
> 
> There are a number of areas that could do with sorting out with regard key
> policy:
> 
>  (1) Should signatures produced by the manager of the linux-firmware package
>      be allowed only?

Firmware is a binary blob usually with no decompilation.  How would the
package manager know its provenance?  The only people who know are the
people who write the driver.  If they sign, I think we have to accept
their signature and if not, we could have a weaker level of trust on the
package manager based on unbroken chain of transmission from the
firmware provider, but you'd have to trust the packaging organisation.

>  (2) If the linux-firmware packages are signed by a single key (or just a few
>      keys) it may be manageable to compile all these keys into the kernel.
> 
>  (3) If the vendors of firmware blobs supply signatures, should we accept
>      those instead of or as well as linux-firmware signatures?

Of course, How are you going to validate other than by trusting the
vendor?  Conversely, if you don't trust the vendor, why are you loading
an unknown binary blob from them into a processing engine they made?

>  (4) If we start taking vendor created blobs, what do we do with all the
>      vendor keys?  Compiling them into the kernel could quickly get out of
>      hand and asking the user to add them to the UEFI keystore has the
>      potential to brick the user's system due to a dodgy BIOS.

If the vendors buy in, I assume you'll eventually get them building them
into their drivers.  In the interim, the package manager could supply
the trusted keys at runtime.

>  (5) For firmware signatures, the patches we have currently expect to find a
>      signed attribute in the PKCS#7 that specifies the same name as is passed
>      to request_firmware().
> 
>  (6) Should module signatures contain the module name - to be matched against
>      the modinfo structure after the signature is checked?

I'm agnostic on this, but if we're doing signatures, we already have the
sha256 of the code.  We can build a simple comparison table, so we can
match to the signature without knowing the name.

>  (7) Do we want to have the driver mandate the key that will be used when
>      requesting firmware?  How would we specify the key?  I'm loathe to
>      include a hash of the public key since that means the driver is then tied
>      to a particular key.

I think so ... how else would you have a true validation chain.  You
need to ask yourself *what* your trusting.  I'm afraid the answer is
whatever the manufacturer told you because there's no way of checking
for firmware.

>  (8) Can we then trust that key if we load it on the basis that a driver
>      specifies it by public key hash, even it we can't chain back from it to
>      the system_trusted_keyring.

What's the point of tying to the system root of trust?

>  (9) Do we allow UEFI blacklisting of firmware signatures?

There has to be a blacklist mechanism, yes ... I'm not sure UEFI would
do it, though.

> Some points that may be of use in considering the above:
> 
>  (A) PKCS#7/CMS messages can take multiple signatures.  Extra signatures can
>      be added at a later date.

This is irrelevant in the detached signature case, isn't it?

>  (B) We can load keys dynamically - provided we can verify them with a key we
>      already have.
> 
>  (C) If we can't trace a key back to a key we know we trust, that key cannot
>      be used.
> 
>  (D) The PKCS#7/CMS field that matches the signing key is not itself signed.

Does it need to be?  If the field is modified, verification occurs with
the wrong key and you get a failure.  That's logically equivalent to
finding the field has been altered and getting a failure.

> If we do have this discussion, it would be useful to have some or all of Luis
> Rodriguez, David Woodhouse, Andy Lutomirski, Kyle McMartin, Seth Forshee and
> Mimi Zohar present.

Since you mention UEFI, you probably need the people who've been deep in
the UEFI signature issue: Peter Jones, Matthew Garrett, Matt Fleming and
me.

James


> David
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:

>  (3) If the vendors of firmware blobs supply signatures, should we accept
>      those instead of or as well as linux-firmware signatures?

Yes, definitely. And in fact that ties in to separate discussions we've
been having about how to automatically *obtain* certain firmware
images, which are signed by Microsoft's AuthentiCode scheme.

People were talking about how to validate those signatures in userspace
when we obtain the firmware. But really, they should be carried all the
way through and validated in the kernel too.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 8:10 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
>> Patches are in the works for the provision of signatures for firmware blobs
>> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
>> firmware blobs get loaded where.
>>
>> Note that it has been agreed that signatures will be in separate files to the
>> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
>> that doesn't expect the signature.  Also, we don't want to modify the blob in
>> case of IP.
>>
>> We're currently using PKCS#7/CMS messages as the signature format since we
>> have a PKCS#7 parser and verifier already in the kernel for kexec.
>>
>> Patches have been proposed for inclusion in security/next that allow PKCS#11
>> to be used to supply h/w keys to the sign-file program and to the kernel build
>> process.
>>
>> There are a number of areas that could do with sorting out with regard key
>> policy:
>>
>>  (1) Should signatures produced by the manager of the linux-firmware package
>>      be allowed only?
>
> Firmware is a binary blob usually with no decompilation.  How would the
> package manager know its provenance?  The only people who know are the
> people who write the driver.  If they sign, I think we have to accept
> their signature and if not, we could have a weaker level of trust on the
> package manager based on unbroken chain of transmission from the
> firmware provider, but you'd have to trust the packaging organisation.

But IMO we really don't want trust $RANDOM_USB_WIDGET_VENDOR to supply
firmware for the GPU, for example.

>>  (8) Can we then trust that key if we load it on the basis that a driver
>>      specifies it by public key hash, even it we can't chain back from it to
>>      the system_trusted_keyring.
>
> What's the point of tying to the system root of trust?
>

Agreed.  See about.  I don't think the concept of trust should be as
simple as "we trust" or "we don't trust" -- we should trust certain
vendors for certain purposes only.

>> If we do have this discussion, it would be useful to have some or all of Luis
>> Rodriguez, David Woodhouse, Andy Lutomirski, Kyle McMartin, Seth Forshee and
>> Mimi Zohar present.
>

I'll be there.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 08:22 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 8:10 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
> >> Patches are in the works for the provision of signatures for firmware blobs
> >> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> >> firmware blobs get loaded where.
> >>
> >> Note that it has been agreed that signatures will be in separate files to the
> >> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> >> that doesn't expect the signature.  Also, we don't want to modify the blob in
> >> case of IP.
> >>
> >> We're currently using PKCS#7/CMS messages as the signature format since we
> >> have a PKCS#7 parser and verifier already in the kernel for kexec.
> >>
> >> Patches have been proposed for inclusion in security/next that allow PKCS#11
> >> to be used to supply h/w keys to the sign-file program and to the kernel build
> >> process.
> >>
> >> There are a number of areas that could do with sorting out with regard key
> >> policy:
> >>
> >>  (1) Should signatures produced by the manager of the linux-firmware package
> >>      be allowed only?
> >
> > Firmware is a binary blob usually with no decompilation.  How would the
> > package manager know its provenance?  The only people who know are the
> > people who write the driver.  If they sign, I think we have to accept
> > their signature and if not, we could have a weaker level of trust on the
> > package manager based on unbroken chain of transmission from the
> > firmware provider, but you'd have to trust the packaging organisation.
> 
> But IMO we really don't want trust $RANDOM_USB_WIDGET_VENDOR to supply
> firmware for the GPU, for example.

I'm not saying that.  I'm saying that if we verify some chain in
firmware, it has to be from a trusted supplier to us, meaning we invest
trust already in the supplier.  However, the trusted supplier should be
the original device vendor.  if $RANDOM_USB_WIGET_VENDOR isn't the
original vendor, then this would not trust them.  If they are, it's
hobson's choice ... and god help us.

I've got a ton of complaints about USB devices that can't be made to
work under Linux without corruption (write cache with no flush and no
means of turning it off) but people demand that we work with them
anyway ... disabling stupid USB devices sounds nice in theory but annoys
your users in practise.

James

> >>  (8) Can we then trust that key if we load it on the basis that a driver
> >>      specifies it by public key hash, even it we can't chain back from it to
> >>      the system_trusted_keyring.
> >
> > What's the point of tying to the system root of trust?
> >
> 
> Agreed.  See about.  I don't think the concept of trust should be as
> simple as "we trust" or "we don't trust" -- we should trust certain
> vendors for certain purposes only.
> 
> >> If we do have this discussion, it would be useful to have some or all of Luis
> >> Rodriguez, David Woodhouse, Andy Lutomirski, Kyle McMartin, Seth Forshee and
> >> Mimi Zohar present.
> >
> 
> I'll be there.
> 
> --Andy
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 8:31 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 08:22 -0700, Andy Lutomirski wrote:
>> On Tue, Jul 28, 2015 at 8:10 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
>> >> Patches are in the works for the provision of signatures for firmware blobs
>> >> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
>> >> firmware blobs get loaded where.
>> >>
>> >> Note that it has been agreed that signatures will be in separate files to the
>> >> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
>> >> that doesn't expect the signature.  Also, we don't want to modify the blob in
>> >> case of IP.
>> >>
>> >> We're currently using PKCS#7/CMS messages as the signature format since we
>> >> have a PKCS#7 parser and verifier already in the kernel for kexec.
>> >>
>> >> Patches have been proposed for inclusion in security/next that allow PKCS#11
>> >> to be used to supply h/w keys to the sign-file program and to the kernel build
>> >> process.
>> >>
>> >> There are a number of areas that could do with sorting out with regard key
>> >> policy:
>> >>
>> >>  (1) Should signatures produced by the manager of the linux-firmware package
>> >>      be allowed only?
>> >
>> > Firmware is a binary blob usually with no decompilation.  How would the
>> > package manager know its provenance?  The only people who know are the
>> > people who write the driver.  If they sign, I think we have to accept
>> > their signature and if not, we could have a weaker level of trust on the
>> > package manager based on unbroken chain of transmission from the
>> > firmware provider, but you'd have to trust the packaging organisation.
>>
>> But IMO we really don't want trust $RANDOM_USB_WIDGET_VENDOR to supply
>> firmware for the GPU, for example.
>
> I'm not saying that.  I'm saying that if we verify some chain in
> firmware, it has to be from a trusted supplier to us, meaning we invest
> trust already in the supplier.  However, the trusted supplier should be
> the original device vendor.  if $RANDOM_USB_WIGET_VENDOR isn't the
> original vendor, then this would not trust them.  If they are, it's
> hobson's choice ... and god help us.

Sure, but we shouldn't stick the USB vendor's key into the system
keyring.  I'm fine with having it in the kernel or in some database,
though.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 09:05 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 8:31 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-07-28 at 08:22 -0700, Andy Lutomirski wrote:
> >> On Tue, Jul 28, 2015 at 8:10 AM, James Bottomley
> >> <James.Bottomley@hansenpartnership.com> wrote:
> >> > On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
> >> >> Patches are in the works for the provision of signatures for firmware blobs
> >> >> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> >> >> firmware blobs get loaded where.
> >> >>
> >> >> Note that it has been agreed that signatures will be in separate files to the
> >> >> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> >> >> that doesn't expect the signature.  Also, we don't want to modify the blob in
> >> >> case of IP.
> >> >>
> >> >> We're currently using PKCS#7/CMS messages as the signature format since we
> >> >> have a PKCS#7 parser and verifier already in the kernel for kexec.
> >> >>
> >> >> Patches have been proposed for inclusion in security/next that allow PKCS#11
> >> >> to be used to supply h/w keys to the sign-file program and to the kernel build
> >> >> process.
> >> >>
> >> >> There are a number of areas that could do with sorting out with regard key
> >> >> policy:
> >> >>
> >> >>  (1) Should signatures produced by the manager of the linux-firmware package
> >> >>      be allowed only?
> >> >
> >> > Firmware is a binary blob usually with no decompilation.  How would the
> >> > package manager know its provenance?  The only people who know are the
> >> > people who write the driver.  If they sign, I think we have to accept
> >> > their signature and if not, we could have a weaker level of trust on the
> >> > package manager based on unbroken chain of transmission from the
> >> > firmware provider, but you'd have to trust the packaging organisation.
> >>
> >> But IMO we really don't want trust $RANDOM_USB_WIDGET_VENDOR to supply
> >> firmware for the GPU, for example.
> >
> > I'm not saying that.  I'm saying that if we verify some chain in
> > firmware, it has to be from a trusted supplier to us, meaning we invest
> > trust already in the supplier.  However, the trusted supplier should be
> > the original device vendor.  if $RANDOM_USB_WIGET_VENDOR isn't the
> > original vendor, then this would not trust them.  If they are, it's
> > hobson's choice ... and god help us.
> 
> Sure, but we shouldn't stick the USB vendor's key into the system
> keyring.  I'm fine with having it in the kernel or in some database,
> though.

Actually, I don't think we should have a general system keyring for
firmware.  We need driver specific ones, so the USB vendor key is *only*
trusted for that particular driver.  Putting vendor keys into our
general keyring would be a recipe for inviting abuse.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 09:10 -0700, James Bottomley wrote:
> 
> > Sure, but we shouldn't stick the USB vendor's key into the system
> > keyring.  I'm fine with having it in the kernel or in some database,
> > though.
> 
> Actually, I don't think we should have a general system keyring for
> firmware.  We need driver specific ones, so the USB vendor key is *only*
> trusted for that particular driver.  Putting vendor keys into our
> general keyring would be a recipe for inviting abuse.

We need both.

Where a firmware is signed by the vendor, the request_firmware() call
itself can provide the hash of the acceptable signing cert. (And we'll
want to handle the firmware we get with MS AuthentiCode signatures on
them in a separate .cat file, as discussed.)

In the case where firmware *doesn't* have a valid signature that comes
all the way from the vendor, a signature that just says "this is what
was in the linux-firmware.git tree" is better than nothing, and *that*
cert can be in the system trusted keyring.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> >  (1) Should signatures produced by the manager of the linux-firmware package
> >      be allowed only?
> 
> Firmware is a binary blob usually with no decompilation.  How would the
> package manager know its provenance?  The only people who know are the
> people who write the driver.  If they sign, I think we have to accept
> their signature and if not, we could have a weaker level of trust on the
> package manager based on unbroken chain of transmission from the
> firmware provider, but you'd have to trust the packaging organisation.

There's an additional question here:

(1b) Assuming we want to reject any firmware blob for which we don't have a
     valid signature, what do we do about things for which we don't have a
     signature?

I'm assuming that we reasonably regard the set of blobs in linux-firmware -
and for the moment we might have to sign them all with the linux-firmware
manager's key.  Now this might be a bad assumption, but we can't practically
say that we require *every* firmware vendor to give us a signature for every
blob before we can guarantee that all of them will work.

> >  (3) If the vendors of firmware blobs supply signatures, should we accept
> >      those instead of or as well as linux-firmware signatures?
> 
> Of course, How are you going to validate other than by trusting the
> vendor?  Conversely, if you don't trust the vendor, why are you loading
> an unknown binary blob from them into a processing engine they made?

As previously mentioned, we have to deal with as-yet unsigned firmware blobs
or the validation can be worked around by simple removing the signature file.

> >  (4) If we start taking vendor created blobs, what do we do with all the
> >      vendor keys?  Compiling them into the kernel could quickly get out of
> >      hand and asking the user to add them to the UEFI keystore has the
> >      potential to brick the user's system due to a dodgy BIOS.
> 
> If the vendors buy in, I assume you'll eventually get them building them
> into their drivers.

You could do that.  But it means if a vendor's private key is compromised, you
have to issue a replacement kernel as well as a replacement firmware package
instead of just the latter.  I guess you have to pick the compromise you're
willing to live with.

> In the interim, the package manager could supply the trusted keys at
> runtime.

Only if they're signed by a key trusted by the kernel - otherwise they aren't
trusted keys.

> >  (6) Should module signatures contain the module name - to be matched
> >      against the modinfo structure after the signature is checked?
> 
> I'm agnostic on this, but if we're doing signatures, we already have the
> sha256 of the code.  We can build a simple comparison table, so we can
> match to the signature without knowing the name.

It would have to be built into the core kernel.  The Fedora kernel I'm running
has 4118 modules available.  That's 32 bytes per module, assuming simply a
flat list of module digests - giving a total table size of ~128K of
uncompressible, unswappable data.  Further, you also cannot load any module
external to that set - so no OpenAFS, no 

> >  (7) Do we want to have the driver mandate the key that will be used when
> >      requesting firmware?  How would we specify the key?  I'm loathe to
> >      include a hash of the public key since that means the driver is then
> >      tied to a particular key.
> 
> I think so ... how else would you have a true validation chain.  You
> need to ask yourself *what* your trusting.  I'm afraid the answer is
> whatever the manufacturer told you because there's no way of checking
> for firmware.

Well, you could theoretically have a validation chain if, say, LF had a root
cert that they signed vendor's keys with that they then used to sign their
firmware and we put the root X.509 cert into the kernel.

Of course, there'd likely be politicking about this and I'm not sure LF would
want to go there...

Also, this assumed that the vendor is interested in supporting Linux and is
willing to provide a cert that the driver can reference...  We have to be able
to support the case where this isn't true - and where a manufacturer no longer
exists or no longer supports a product.

> >  (8) Can we then trust that key if we load it on the basis that a driver
> >      specifies it by public key hash, even it we can't chain back from it to
> >      the system_trusted_keyring.
> 
> What's the point of tying to the system root of trust?

Because then we can demand-load keys using add_key() or request_key() and
validate their trust by chaining.

> >  (9) Do we allow UEFI blacklisting of firmware signatures?
> 
> There has to be a blacklist mechanism, yes ... I'm not sure UEFI would
> do it, though.

IIRC, UEFI blacklisting is just a list of SHA256 hashes.

However, we could also have a list of SHA256 hashes and names in the
linux-firmware package with its own signature that we can demand load using
request_firmware().

> > Some points that may be of use in considering the above:
> > 
> >  (A) PKCS#7/CMS messages can take multiple signatures.  Extra signatures can
> >      be added at a later date.
> 
> This is irrelevant in the detached signature case, isn't it?

No.  The PKCS#7 message file that is the 'signature' can have multiple digital
signatures by different keys.  As far as the PKCS#7 message is concerned, it's
the content that is detached.

> >  (D) The PKCS#7/CMS field that matches the signing key is not itself signed.
> 
> Does it need to be?  If the field is modified, verification occurs with
> the wrong key and you get a failure.  That's logically equivalent to
> finding the field has been altered and getting a failure.

My point was that an Intel driver, say, can't say that "You must use a key
with subject /CN=Intel firmware/O=Intel" as anyone can create such a key and a
fake firmware blob that requires that key.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Andy Lutomirski <luto@amacapital.net> wrote:

> Agreed.  See about.  I don't think the concept of trust should be as
> simple as "we trust" or "we don't trust" -- we should trust certain
> vendors for certain purposes only.

How do you deal with a big vendor, like Intel, that makes lots of different
bits for lots of different purposes?

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 9:15 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2015-07-28 at 09:10 -0700, James Bottomley wrote:
>>
>> > Sure, but we shouldn't stick the USB vendor's key into the system
>> > keyring.  I'm fine with having it in the kernel or in some database,
>> > though.
>>
>> Actually, I don't think we should have a general system keyring for
>> firmware.  We need driver specific ones, so the USB vendor key is *only*
>> trusted for that particular driver.  Putting vendor keys into our
>> general keyring would be a recipe for inviting abuse.
>
> We need both.
>
> Where a firmware is signed by the vendor, the request_firmware() call
> itself can provide the hash of the acceptable signing cert. (And we'll
> want to handle the firmware we get with MS AuthentiCode signatures on
> them in a separate .cat file, as discussed.)
>
> In the case where firmware *doesn't* have a valid signature that comes
> all the way from the vendor, a signature that just says "this is what
> was in the linux-firmware.git tree" is better than nothing, and *that*
> cert can be in the system trusted keyring.
>

I'd really like to replace "the system trusted keyring" with
purpose-specific lists of keys.  There are keys we trust to sign
modules, there are keys we trust to sign kexec things, there will be
keys to trust to sign firmware for any device, etc.

Even now, I think we're conflating keys that we shouldn't conflate.
Arguably the keys for kexec and the keys for modules should be
different, because loading a module really gives you the right to do
anything, as does loading a kexec image without poking the TPM PCRs,
but I think we might want keys that can only sign kexec images that
are loaded after poking PCRs.  Crash kernels are in the latter
category.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 17:18 +0100, David Howells wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
> 
> > Agreed.  See about.  I don't think the concept of trust should be as
> > simple as "we trust" or "we don't trust" -- we should trust certain
> > vendors for certain purposes only.
> 
> How do you deal with a big vendor, like Intel, that makes lots of different
> bits for lots of different purposes?

I don't understand what you think the problem is?  What's not clear
about "we have to trust the vendor".  If they choose to use a single key
for multiple drivers, it's no more or less a problem than if they choose
multiple keys, one for each driver.

I think the trust we're investing is in the provenance of the blob, not
the blob itself, so the firmware can't be substituted with a malicious
version by an outside entity.  If we don't trust the firmware vendor,
then all bets are off and the provenance chain is pretty meaningless.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Andy Lutomirski <luto@amacapital.net> wrote:

> I'd really like to replace "the system trusted keyring" with
> purpose-specific lists of keys.  There are keys we trust to sign
> modules, there are keys we trust to sign kexec things, there will be
> keys to trust to sign firmware for any device, etc.

I have some patches to restrict what a key is permitted to do - see the top
few patches here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fwsign-pkcs7

This involves marking the X.509 certs with the intended use case (or relying
on the existing CA stuff for key-signing keys).

I do put all the keys into one keyring on the basis that each key will be used
once and won't be added multiple times through separate X.509 certs that give
different usage restrictions for the same key.  Given this, having just one
keyring works fine.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 7:23 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>>  (2) If the linux-firmware packages are signed by a single key (or just a few
>>      keys) it may be manageable to compile all these keys into the kernel.
>
> I really think we want to allow firmware to be signed by the vendor who
> created it — and we want the linux-firmware.git repository to carry the
> original vendors' signatures along with the firmware blobs.
>
> Having a signature generated by the linux-firmware packager which just
> certifies that this *is* the blob that was in the linux-firmware.git
> repository is only a partial solution.

As we have it now the fist iteration of patches would just allow to
trust a set a key signed by a trusted CA for the purpose firmware
signing, and each firmware signature must be signed with a key
intended for the purpose of firmware singing, additionally the
signature would have the file name  for the intended signature.
Support for embedding a custom set of key attribute requirements is
part of my second phase of firmware signing patches, to help replace
CRDA with in-kernel functionality as that is one existing use case
where what you say is what we needed. The second phase of patches
would also allow drivers to make use of this though -- so what you say
would be supported, but it would come in with the second set of
patches. The reason it'd come in separately is the firmware API is
already abused enough, we keep adding new routines with more arguments
and I think that needs to end. The second set of patches introduce a
new extensible API which lets users express the requirements for the
"system data file" and then the core vets for its ability to meet the
criteria passed and if it can find it, it hands it back.

There's one caveat here, at least the way me and David envisioned
system data extensions is that you'd have to register an OID into the
kernel's registry and your key would have to be purposed for that OID.
David mentions we don't have a limit to the OID registry but I don't
think we were envisioning everyone having a custom set of
requirements, although I cannot foresee any issues with this, other
than the kernel size overhead. We did speak about dynamic extensions
to this registry, so maybe that's the way to make it less of pain to
the kernel's size. Perhaps the later should be something some vendors
can opt-in to. That would provide for the flexibility to only those
using those APIs (ie Intel), meanwhile if a distro disables firmware
singing its all ignored, the next step would be if they enable
firmware singing then the default trusted key (Kyle's) would be
trusted. The system data API would enable subsystems and drivers to
*require* a signature independent of what the distro
said to firmware signing, ie, a different Kconfig entry. This would
enable a silicon vendor to require signed firmware, and it'd work, so
long as it was in linux-firmware, and the distro would not need
firmware signing enabled.

 Luis

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Josh Boyer]

On Tue, Jul 28, 2015 at 11:10 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
>> Patches are in the works for the provision of signatures for firmware blobs
>> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
>> firmware blobs get loaded where.
>>
>> Note that it has been agreed that signatures will be in separate files to the
>> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
>> that doesn't expect the signature.  Also, we don't want to modify the blob in
>> case of IP.
>>
>> We're currently using PKCS#7/CMS messages as the signature format since we
>> have a PKCS#7 parser and verifier already in the kernel for kexec.
>>
>> Patches have been proposed for inclusion in security/next that allow PKCS#11
>> to be used to supply h/w keys to the sign-file program and to the kernel build
>> process.
>>
>> There are a number of areas that could do with sorting out with regard key
>> policy:
>>
>>  (1) Should signatures produced by the manager of the linux-firmware package
>>      be allowed only?
>
> Firmware is a binary blob usually with no decompilation.  How would the
> package manager know its provenance?  The only people who know are the
> people who write the driver.  If they sign, I think we have to accept
> their signature and if not, we could have a weaker level of trust on the
> package manager based on unbroken chain of transmission from the
> firmware provider, but you'd have to trust the packaging organisation.

Packagers signing individual firmware files seems wrong.  As a
packager, I would want my signature to represent the fact that I
created this package and it is official in some capacity.  That
signature would naturally be on the package itself, e.g. an RPM
signature.

>>  (2) If the linux-firmware packages are signed by a single key (or just a few
>>      keys) it may be manageable to compile all these keys into the kernel.
>>
>>  (3) If the vendors of firmware blobs supply signatures, should we accept
>>      those instead of or as well as linux-firmware signatures?
>
> Of course, How are you going to validate other than by trusting the
> vendor?  Conversely, if you don't trust the vendor, why are you loading
> an unknown binary blob from them into a processing engine they made?
>
>>  (4) If we start taking vendor created blobs, what do we do with all the
>>      vendor keys?  Compiling them into the kernel could quickly get out of
>>      hand and asking the user to add them to the UEFI keystore has the
>>      potential to brick the user's system due to a dodgy BIOS.
>
> If the vendors buy in, I assume you'll eventually get them building them
> into their drivers.  In the interim, the package manager could supply
> the trusted keys at runtime.

Yes, adding them to the driver itself seems like the least painful
solution there.

josh

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 17:17 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > >  (1) Should signatures produced by the manager of the linux-firmware package
> > >      be allowed only?
> > 
> > Firmware is a binary blob usually with no decompilation.  How would the
> > package manager know its provenance?  The only people who know are the
> > people who write the driver.  If they sign, I think we have to accept
> > their signature and if not, we could have a weaker level of trust on the
> > package manager based on unbroken chain of transmission from the
> > firmware provider, but you'd have to trust the packaging organisation.
> 
> There's an additional question here:
> 
> (1b) Assuming we want to reject any firmware blob for which we don't have a
>      valid signature, what do we do about things for which we don't have a
>      signature?
> 
> I'm assuming that we reasonably regard the set of blobs in linux-firmware -
> and for the moment we might have to sign them all with the linux-firmware
> manager's key.  Now this might be a bad assumption, but we can't practically
> say that we require *every* firmware vendor to give us a signature for every
> blob before we can guarantee that all of them will work.

We can make it optional.  The driver already encodes for the firmware
location and version, if it uses request_firmware, it can easily add a
signing key field.

> > >  (3) If the vendors of firmware blobs supply signatures, should we accept
> > >      those instead of or as well as linux-firmware signatures?
> > 
> > Of course, How are you going to validate other than by trusting the
> > vendor?  Conversely, if you don't trust the vendor, why are you loading
> > an unknown binary blob from them into a processing engine they made?
> 
> As previously mentioned, we have to deal with as-yet unsigned firmware blobs
> or the validation can be worked around by simple removing the signature file.

Look, you're implying signed == trusted, right?  If we start signing
stuff we're not sure should be trusted that explodes the whole model.
Therefore, you need to establish two things

     1. What is it that we actually trust?  (I think it's the
        transmission path from the firmware supplier, but you haven't
        said)
     2. If we can't validate 1, what do we do

For 2. I think you need to leave stuff you can't validate 1. for
unsigned and let system policy decide.  Signing is implying a trust you
don't have and thus corrupting the trust model.

> > >  (4) If we start taking vendor created blobs, what do we do with all the
> > >      vendor keys?  Compiling them into the kernel could quickly get out of
> > >      hand and asking the user to add them to the UEFI keystore has the
> > >      potential to brick the user's system due to a dodgy BIOS.
> > 
> > If the vendors buy in, I assume you'll eventually get them building them
> > into their drivers.
> 
> You could do that.  But it means if a vendor's private key is compromised, you
> have to issue a replacement kernel as well as a replacement firmware package
> instead of just the latter.  I guess you have to pick the compromise you're
> willing to live with.

In the real world, what vendor would be willing to admit their private
key is compromised ... do you know the amount of trouble that would
cause with their trust for other things, like UEFI ...

However, we handle in the same way.  Global key or sig blacklist.

> > In the interim, the package manager could supply the trusted keys at
> > runtime.
> 
> Only if they're signed by a key trusted by the kernel - otherwise they aren't
> trusted keys.

That depends what model we use to convey trust.  It's the same problem
as adding a key to the kernel keyring ... one for which we have an
existing set of solutions.

> > >  (6) Should module signatures contain the module name - to be matched
> > >      against the modinfo structure after the signature is checked?
> > 
> > I'm agnostic on this, but if we're doing signatures, we already have the
> > sha256 of the code.  We can build a simple comparison table, so we can
> > match to the signature without knowing the name.
> 
> It would have to be built into the core kernel.  The Fedora kernel I'm running
> has 4118 modules available.  That's 32 bytes per module, assuming simply a
> flat list of module digests - giving a total table size of ~128K of
> uncompressible, unswappable data.  Further, you also cannot load any module
> external to that set - so no OpenAFS, no 

Why not? ... you seem to have some model in your head that you haven't
fully elucidated, could you share.  The firmware key database would have
to be mutable.  That allows adding arbitrary keys at any time.

> > >  (7) Do we want to have the driver mandate the key that will be used when
> > >      requesting firmware?  How would we specify the key?  I'm loathe to
> > >      include a hash of the public key since that means the driver is then
> > >      tied to a particular key.
> > 
> > I think so ... how else would you have a true validation chain.  You
> > need to ask yourself *what* your trusting.  I'm afraid the answer is
> > whatever the manufacturer told you because there's no way of checking
> > for firmware.
> 
> Well, you could theoretically have a validation chain if, say, LF had a root
> cert that they signed vendor's keys with that they then used to sign their
> firmware and we put the root X.509 cert into the kernel.

No, that's Andy's point.  I don't trust fly by night USB vendor to have
a key in my total trust ring.  We need a segmented trust model.

> Of course, there'd likely be politicking about this and I'm not sure LF would
> want to go there...

The global one key to rule them all trust model doesn't work for this.
However, a certificate constraint setting the actual constraint properly
would.

> Also, this assumed that the vendor is interested in supporting Linux and is
> willing to provide a cert that the driver can reference...  We have to be able
> to support the case where this isn't true - and where a manufacturer no longer
> exists or no longer supports a product.

That comes down to what do you trust, see above.

> > >  (8) Can we then trust that key if we load it on the basis that a driver
> > >      specifies it by public key hash, even it we can't chain back from it to
> > >      the system_trusted_keyring.
> > 
> > What's the point of tying to the system root of trust?
> 
> Because then we can demand-load keys using add_key() or request_key() and
> validate their trust by chaining.

Right, so this is an update model, but for the current global trust
database.  As has been discussed above this is too dangerous for third
party firmware keys.

> > >  (9) Do we allow UEFI blacklisting of firmware signatures?
> > 
> > There has to be a blacklist mechanism, yes ... I'm not sure UEFI would
> > do it, though.
> 
> IIRC, UEFI blacklisting is just a list of SHA256 hashes.

No, it isn't, that might be why UEFI people present, who've already been
dealing with this for UEFI driver blobs, might be sensible.

The current MS policy is hashes only, but dbx can have keys as well.

> However, we could also have a list of SHA256 hashes and names in the
> linux-firmware package with its own signature that we can demand load using
> request_firmware().

That means no firmware update without kernel update ... why not just
build the firmware in in that case?

> > > Some points that may be of use in considering the above:
> > > 
> > >  (A) PKCS#7/CMS messages can take multiple signatures.  Extra signatures can
> > >      be added at a later date.
> > 
> > This is irrelevant in the detached signature case, isn't it?
> 
> No.  The PKCS#7 message file that is the 'signature' can have multiple digital
> signatures by different keys.  As far as the PKCS#7 message is concerned, it's
> the content that is detached.

I mean you can have n files each with one signature, even if the format
didn't support n signatures in one file ... essentially rendering the
problem irrelevant.

> > >  (D) The PKCS#7/CMS field that matches the signing key is not itself signed.
> > 
> > Does it need to be?  If the field is modified, verification occurs with
> > the wrong key and you get a failure.  That's logically equivalent to
> > finding the field has been altered and getting a failure.
> 
> My point was that an Intel driver, say, can't say that "You must use a key
> with subject /CN=Intel firmware/O=Intel" as anyone can create such a key and a
> fake firmware blob that requires that key.

X509 already solved this.  The authority key identifier explains how to
encode trust of a public key.  We don't have to use their solution, but
equally we don't have to fret about problems the security community
already addressed.

James

> David
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 9:44 AM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> I'd really like to replace "the system trusted keyring" with
>> purpose-specific lists of keys.  There are keys we trust to sign
>> modules, there are keys we trust to sign kexec things, there will be
>> keys to trust to sign firmware for any device, etc.
>
> I have some patches to restrict what a key is permitted to do - see the top
> few patches here:
>
>         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fwsign-pkcs7
>
> This involves marking the X.509 certs with the intended use case (or relying
> on the existing CA stuff for key-signing keys).

This will require that we take any firmware vendor's key and rewrap it
somehow into a new X.509 blob with a key usage constraint.

Can't we just track this stuff in the kernel without adding yet
another dependency on X.509?

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 9:42 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 17:18 +0100, David Howells wrote:
>> Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> > Agreed.  See about.  I don't think the concept of trust should be as
>> > simple as "we trust" or "we don't trust" -- we should trust certain
>> > vendors for certain purposes only.
>>
>> How do you deal with a big vendor, like Intel, that makes lots of different
>> bits for lots of different purposes?
>
> I don't understand what you think the problem is?  What's not clear
> about "we have to trust the vendor".  If they choose to use a single key
> for multiple drivers, it's no more or less a problem than if they choose
> multiple keys, one for each driver.
>
> I think the trust we're investing is in the provenance of the blob, not
> the blob itself, so the firmware can't be substituted with a malicious
> version by an outside entity.  If we don't trust the firmware vendor,
> then all bets are off and the provenance chain is pretty meaningless.

I think we disagree on the scope of the trust.  I trust the USB widget
vendor to provide firmware for the USB widget.  I might as well trust
them to sign the firmware itself and to provide new signed blobs by
any means (web, email, shoved in a directory, whatever).  I have no
choice anyway, since they provided the device in the first place and
they could have burnt anything they wanted into it.

This does not mean that their key should be acceptable for kexec
images, modules, GPU firmware, firmware for different vendors' USB
sticks, firmware for my hard disk, etc.  In fact I flat out distrust
them if they ever try to provide such blobs.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 10:05 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 9:42 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2015-07-28 at 17:18 +0100, David Howells wrote:
> >> Andy Lutomirski <luto@amacapital.net> wrote:
> >>
> >> > Agreed.  See about.  I don't think the concept of trust should be as
> >> > simple as "we trust" or "we don't trust" -- we should trust certain
> >> > vendors for certain purposes only.
> >>
> >> How do you deal with a big vendor, like Intel, that makes lots of different
> >> bits for lots of different purposes?
> >
> > I don't understand what you think the problem is?  What's not clear
> > about "we have to trust the vendor".  If they choose to use a single key
> > for multiple drivers, it's no more or less a problem than if they choose
> > multiple keys, one for each driver.
> >
> > I think the trust we're investing is in the provenance of the blob, not
> > the blob itself, so the firmware can't be substituted with a malicious
> > version by an outside entity.  If we don't trust the firmware vendor,
> > then all bets are off and the provenance chain is pretty meaningless.
> 
> I think we disagree on the scope of the trust.

We do?

>   I trust the USB widget
> vendor to provide firmware for the USB widget.  I might as well trust
> them to sign the firmware itself and to provide new signed blobs by
> any means (web, email, shoved in a directory, whatever).  I have no
> choice anyway, since they provided the device in the first place and
> they could have burnt anything they wanted into it.

You think I'd trust a USB vendor signature on my enterprise disk
firmware? ... how did I give that impression?

The signature gives provenance, but we still have to verify that the
attested origin is allowed to update the given object.

> This does not mean that their key should be acceptable for kexec
> images, modules, GPU firmware, firmware for different vendors' USB
> sticks, firmware for my hard disk, etc.  In fact I flat out distrust
> them if they ever try to provide such blobs.

Um, I do believe we agree here.

James

> --Andy
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 10:09 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2015-07-28 at 10:05 -0700, Andy Lutomirski wrote:
>> On Tue, Jul 28, 2015 at 9:42 AM, James Bottomley
>> <James.Bottomley@hansenpartnership.com> wrote:
>> > On Tue, 2015-07-28 at 17:18 +0100, David Howells wrote:
>> >> Andy Lutomirski <luto@amacapital.net> wrote:
>> >>
>> >> > Agreed.  See about.  I don't think the concept of trust should be as
>> >> > simple as "we trust" or "we don't trust" -- we should trust certain
>> >> > vendors for certain purposes only.
>> >>
>> >> How do you deal with a big vendor, like Intel, that makes lots of different
>> >> bits for lots of different purposes?
>> >
>> > I don't understand what you think the problem is?  What's not clear
>> > about "we have to trust the vendor".  If they choose to use a single key
>> > for multiple drivers, it's no more or less a problem than if they choose
>> > multiple keys, one for each driver.
>> >
>> > I think the trust we're investing is in the provenance of the blob, not
>> > the blob itself, so the firmware can't be substituted with a malicious
>> > version by an outside entity.  If we don't trust the firmware vendor,
>> > then all bets are off and the provenance chain is pretty meaningless.
>>
>> I think we disagree on the scope of the trust.
>
> We do?
>
>>   I trust the USB widget
>> vendor to provide firmware for the USB widget.  I might as well trust
>> them to sign the firmware itself and to provide new signed blobs by
>> any means (web, email, shoved in a directory, whatever).  I have no
>> choice anyway, since they provided the device in the first place and
>> they could have burnt anything they wanted into it.
>
> You think I'd trust a USB vendor signature on my enterprise disk
> firmware? ... how did I give that impression?
>
> The signature gives provenance, but we still have to verify that the
> attested origin is allowed to update the given object.
>
>> This does not mean that their key should be acceptable for kexec
>> images, modules, GPU firmware, firmware for different vendors' USB
>> sticks, firmware for my hard disk, etc.  In fact I flat out distrust
>> them if they ever try to provide such blobs.
>
> Um, I do believe we agree here.

Good. :)  I misunderstood your email.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[josh]

On Tue, Jul 28, 2015 at 02:36:59PM +0100, David Howells wrote:
> Patches are in the works for the provision of signatures for firmware blobs
> for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> firmware blobs get loaded where.
> 
> Note that it has been agreed that signatures will be in separate files to the
> firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> that doesn't expect the signature.  Also, we don't want to modify the blob in
> case of IP.
> 
> We're currently using PKCS#7/CMS messages as the signature format since we
> have a PKCS#7 parser and verifier already in the kernel for kexec.
> 
> Patches have been proposed for inclusion in security/next that allow PKCS#11
> to be used to supply h/w keys to the sign-file program and to the kernel build
> process.

What's the advantage to using signatures here, rather than hashes?

What if we just made request_firmware take a cryptographically secure
hash, and verify that the firmware supplied by userspace has that hash?
Ideally, different firmware should have a different version, and often
the kernel driver knows the specific versions it works with.

The main advantage of signatures would be the ability to update the
firmware *without* updating the driver.  Is that a feature?  Is it
really a problem to add a hash to the driver?

- Josh Triplett

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 11:36 -0700, josh@joshtriplett.org wrote:
> On Tue, Jul 28, 2015 at 02:36:59PM +0100, David Howells wrote:
> > Patches are in the works for the provision of signatures for firmware blobs
> > for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> > firmware blobs get loaded where.
> > 
> > Note that it has been agreed that signatures will be in separate files to the
> > firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> > that doesn't expect the signature.  Also, we don't want to modify the blob in
> > case of IP.
> > 
> > We're currently using PKCS#7/CMS messages as the signature format since we
> > have a PKCS#7 parser and verifier already in the kernel for kexec.
> > 
> > Patches have been proposed for inclusion in security/next that allow PKCS#11
> > to be used to supply h/w keys to the sign-file program and to the kernel build
> > process.
> 
> What's the advantage to using signatures here, rather than hashes?
> 
> What if we just made request_firmware take a cryptographically secure
> hash, and verify that the firmware supplied by userspace has that hash?
> Ideally, different firmware should have a different version, and often
> the kernel driver knows the specific versions it works with.
> 
> The main advantage of signatures would be the ability to update the
> firmware *without* updating the driver.  Is that a feature?  Is it
> really a problem to add a hash to the driver?

So in that case, what's the advantage of separating the firmware from
the driver?  If we can't update it without updating the driver, we could
just build it in and save a huge amount of hassle.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Peter Jones]

On Tue, Jul 28, 2015 at 04:12:06PM +0100, David Woodhouse wrote:
> On Tue, 2015-07-28 at 14:36 +0100, David Howells wrote:
> 
> >  (3) If the vendors of firmware blobs supply signatures, should we accept
> >      those instead of or as well as linux-firmware signatures?
> 
> Yes, definitely. And in fact that ties in to separate discussions we've
> been having about how to automatically *obtain* certain firmware
> images, which are signed by Microsoft's AuthentiCode scheme.
> 
> People were talking about how to validate those signatures in userspace
> when we obtain the firmware. But really, they should be carried all the
> way through and validated in the kernel too.

And even past there - if the firmware update is compliant with NIST
SP800-147 (which they really all /should/ be, but we know how that
goes), then the actual blob that gets passed to the firmware still must
be signed with a key trusted by the firmware.

The standard says (this is the summary section, but the whole thing is
only 26 pages):
  
  2. 	 BIOS Update Authentication

  
  2-A 	 There shall be a Root of Trust for Update (RTU) that contains a
  signature verification algorithm and a key store that includes the
  public key needed to verify the signature on the BIOS update image. 

  
  2-B 	 The key store and the signature verification algorithm shall be
  stored in a protected fashion on the computer system and shall be
  modifiable only using an authenticated update mechanism or a secure
  local update mechanism as outlined in Section 3.1.2. 

  
  2-C 	 The key store in the RTU shall include the public key for
  verifying the signature on a BIOS update image or include the hash
  [FIPS 180-3] of the public key for verifying the signature on a BIOS
  update image that includes the public key. In the latter case, the
  update mechanism shall ensure that the hash of the public key provided
  with the BIOS update image appears in the key store before using the
  provided public key to verify the signature on the BIOS update image.
  

  
  2-D 	 BIOS images shall be signed in conformance with NIST SP 800-89,
  Recommendation for Obtaining Assurances for Digital Signature
  Applications [SP800-89], using an approved digital signature algorithm
  as specified in NIST FIPS 186-3, Digital Signature Standard
  [FIPS186-3], that provides at least 112 bits of security strength, in
  accordance with NIST SP 800-131A, Transitions: Recommendation for
  Transitioning the Use of Cryptographic Algorithms and Key Lengths
  [SP800-131A]. 

  
  2-E 	 The authenticated update mechanism shall ensure that the BIOS
  update image has been digitally signed and that the digital signature
  can be verified using one of the keys in the key store in the RTU
  before updating the BIOS. 


(elsewhere it defines BIOS quite broadly.)

Now, of course this is a NIST "Recommendations" "Special Publication",
not an actual National Standard or ISO document or anything else, but if
you ask e.g. Dell or Insyde or others if their Capsule updates are
compliant, many of them are.

TBH I'm not sure we shouldn't put up a big disclaimer that says you
aren't allowed be using our update system unless they are.

-- 
        Peter

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[josh]

On Tue, Jul 28, 2015 at 11:44:21AM -0700, James Bottomley wrote:
> On Tue, 2015-07-28 at 11:36 -0700, josh@joshtriplett.org wrote:
> > On Tue, Jul 28, 2015 at 02:36:59PM +0100, David Howells wrote:
> > > Patches are in the works for the provision of signatures for firmware blobs
> > > for the kernel to check, thus allowing the kernel to act as gatekeeper on what
> > > firmware blobs get loaded where.
> > > 
> > > Note that it has been agreed that signatures will be in separate files to the
> > > firmware blobs so as not to potentially corrupt a blob by copying it to an OS
> > > that doesn't expect the signature.  Also, we don't want to modify the blob in
> > > case of IP.
> > > 
> > > We're currently using PKCS#7/CMS messages as the signature format since we
> > > have a PKCS#7 parser and verifier already in the kernel for kexec.
> > > 
> > > Patches have been proposed for inclusion in security/next that allow PKCS#11
> > > to be used to supply h/w keys to the sign-file program and to the kernel build
> > > process.
> > 
> > What's the advantage to using signatures here, rather than hashes?
> > 
> > What if we just made request_firmware take a cryptographically secure
> > hash, and verify that the firmware supplied by userspace has that hash?
> > Ideally, different firmware should have a different version, and often
> > the kernel driver knows the specific versions it works with.
> > 
> > The main advantage of signatures would be the ability to update the
> > firmware *without* updating the driver.  Is that a feature?  Is it
> > really a problem to add a hash to the driver?
> 
> So in that case, what's the advantage of separating the firmware from
> the driver?  If we can't update it without updating the driver, we could
> just build it in and save a huge amount of hassle.

Licensing, which is a large part of why we have request_firmware to
begin with.  Let's not make distribution kernel maintainers' lives more
difficult than they already are.

For the drivers I'm most familiar with, new versions of firmware have
new filenames and are requested from userspace in most-preferred to
least-preferred order.  The expectation of those drivers is that any
given firmware version should be binary-identical.

Are there drivers for which the expected firmware update cycle is *more*
rapid than the kernel release cycle?  That would be quite a surprise,
though not an unpleasant one.

- Josh Triplett

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 11:54 AM,  <josh@joshtriplett.org> wrote:
> On Tue, Jul 28, 2015 at 11:44:21AM -0700, James Bottomley wrote:
>> On Tue, 2015-07-28 at 11:36 -0700, josh@joshtriplett.org wrote:
>> > On Tue, Jul 28, 2015 at 02:36:59PM +0100, David Howells wrote:
>> > > Patches are in the works for the provision of signatures for firmware blobs
>> > > for the kernel to check, thus allowing the kernel to act as gatekeeper on what
>> > > firmware blobs get loaded where.
>> > >
>> > > Note that it has been agreed that signatures will be in separate files to the
>> > > firmware blobs so as not to potentially corrupt a blob by copying it to an OS
>> > > that doesn't expect the signature.  Also, we don't want to modify the blob in
>> > > case of IP.
>> > >
>> > > We're currently using PKCS#7/CMS messages as the signature format since we
>> > > have a PKCS#7 parser and verifier already in the kernel for kexec.
>> > >
>> > > Patches have been proposed for inclusion in security/next that allow PKCS#11
>> > > to be used to supply h/w keys to the sign-file program and to the kernel build
>> > > process.
>> >
>> > What's the advantage to using signatures here, rather than hashes?
>> >
>> > What if we just made request_firmware take a cryptographically secure
>> > hash, and verify that the firmware supplied by userspace has that hash?
>> > Ideally, different firmware should have a different version, and often
>> > the kernel driver knows the specific versions it works with.
>> >
>> > The main advantage of signatures would be the ability to update the
>> > firmware *without* updating the driver.  Is that a feature?  Is it
>> > really a problem to add a hash to the driver?
>>
>> So in that case, what's the advantage of separating the firmware from
>> the driver?  If we can't update it without updating the driver, we could
>> just build it in and save a huge amount of hassle.
>
> Licensing, which is a large part of why we have request_firmware to
> begin with.

Not really, we have open source firmare now, both one under GPLv2 for
carl9170 [0], and then ath9k_htc [1] firmware under the Clear BSD
license which explicitly removes the the patent all patent grants [2],
that strategy however is now incompatible with the linux-firmware
policy which requires implicit or explicit patent grants provided [3].

The open firmware projects proved that open firmware works and is the
best engineering solution, what you end up putting in firmware just
needs to be engineered and tested best in collaboration *with* the
community, it doesn't mean you don't need firmware if you have the
hardware capability to use something for it.

[0] https://wireless.wiki.kernel.org/en/users/drivers/carl9170
[1] https://wireless.wiki.kernel.org/en/users/drivers/ath9k_htc
[2] https://github.com/qca/open-ath9k-htc-firmware/blob/master/LICENCE.TXT
[3] https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d3cf09a9765672a7f67991ec4fb64f3d92b387ba

> Let's not make distribution kernel maintainers' lives more
> difficult than they already are.

They can just disable firmware signing.

> For the drivers I'm most familiar with, new versions of firmware have
> new filenames and are requested from userspace in most-preferred to
> least-preferred order.  The expectation of those drivers is that any
> given firmware version should be binary-identical.
>
> Are there drivers for which the expected firmware update cycle is *more*
> rapid than the kernel release cycle?  That would be quite a surprise,
> though not an unpleasant one.

On open firmware this can happen but that is not the reason to have
firmware signing.

 Luis

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> > (1b) Assuming we want to reject any firmware blob for which we don't have a
> >      valid signature, what do we do about things for which we don't have a
> >      signature?
> > 
> > I'm assuming that we reasonably regard the set of blobs in linux-firmware -
> > and for the moment we might have to sign them all with the linux-firmware
> > manager's key.  Now this might be a bad assumption, but we can't practically
> > say that we require *every* firmware vendor to give us a signature for every
> > blob before we can guarantee that all of them will work.
> 
> We can make it optional.  The driver already encodes for the firmware
> location and version, if it uses request_firmware, it can easily add a
> signing key field.

Optional, as in the driver decides whether to use the facility?  or optional
as in we only check the signature if it is present and allow the firmware if
there's no signature?

> > > >  (3) If the vendors of firmware blobs supply signatures, should we
> > > >      accept those instead of or as well as linux-firmware signatures?
> > > 
> > > Of course, How are you going to validate other than by trusting the
> > > vendor?  Conversely, if you don't trust the vendor, why are you loading
> > > an unknown binary blob from them into a processing engine they made?
> > 
> > As previously mentioned, we have to deal with as-yet unsigned firmware
> > blobs or the validation can be worked around by simple removing the
> > signature file.
> 
> Look, you're implying signed == trusted, right?

Not entirely.  Built-in is trusted implicitly.  But we need to go from what we
have built in.

Now, we can decide that we're happy with either building an X.509 cert into a
driver or just a sha256 sum and using that to autoload the cert on a temporary
basis.  But we're going from built-in data.

> If we start signing
> stuff we're not sure should be trusted that explodes the whole model.
> Therefore, you need to establish two things
> 
>      1. What is it that we actually trust?  (I think it's the
>         transmission path from the firmware supplier, but you haven't
>         said)

I acknowledge this is a tricky point.  Currently, we don't have signatures
from vendors that we can use.  What we have is blobs either grabbed from
websites, extracted from Windows installations or provided by the vendor
directly.  Basically, we cannot trust *anything* we have at the moment.

>      2. If we can't validate 1, what do we do

We need a fallback option.  Possibly one that can be enabled/disabled from the
kernel command line that allows firmware blobs with signatures set by the
linux-firmware maintainer indicating this is, to our best knowledge, a valid
blob.  However, that does raise the issue of how you rescind that indication.

> For 2. I think you need to leave stuff you can't validate 1. for
> unsigned and let system policy decide.  Signing is implying a trust you
> don't have and thus corrupting the trust model.

That's a fair point.

I guess what you want is:

 (1) A driver can provide a key in some fashion (exact mechanism TBD), then we
     only permit firmware signed by that key.

 (2) If driver provides a key but the firmware doesn't have an associated
     signature, we reject it.

 (3) A driver can provide a hash of the firmware content and only that exact
     firmware blob is permitted (or possibly a list of alternative hashes).

 (4) If a driver doesn't provide a key, we always accept the firmware.

Which means that someone can use firmware for a driver that falls into
category (4) as an attack mechanism.  Ideally, I'd like to close (4)
entirely.  We could instead:

 (4) If the firmware is signed by the linux-firmware key, we log a warning but
     accept the firmware.

 (5) We reject the firmware.

Now, if we want to load keys from a userspace store by hash, we can have
request_key() do that simply enough.

Is it possible for someone to fabricate a key pair that has a specific public
key but a random private key?  I think from the maths it's impractical in
useful time.

> In the real world, what vendor would be willing to admit their private
> key is compromised ... do you know the amount of trouble that would
> cause with their trust for other things, like UEFI ...

Microsoft might kill their key through a UEFI blacklist if it allows someone
to break into Windows.

> > > >  (6) Should module signatures contain the module name - to be matched
> > > >      against the modinfo structure after the signature is checked?
> > > 
> > > I'm agnostic on this, but if we're doing signatures, we already have the
> > > sha256 of the code.  We can build a simple comparison table, so we can
> > > match to the signature without knowing the name.
> > 
> > It would have to be built into the core kernel.  The Fedora kernel I'm
> > running has 4118 modules available.  That's 32 bytes per module, assuming
> > simply a flat list of module digests - giving a total table size of ~128K
> > of uncompressible, unswappable data.  Further, you also cannot load any
> > module external to that set - so no OpenAFS, no
> 
> Why not? ... you seem to have some model in your head that you haven't
> fully elucidated, could you share.

If you have a 'simple comparison table' then presumably you have to reject
anything not in the table - otherwise what's the point having the table?

I'm assuming you're thinking that we gather digests of all 4118 modules, cat
them together into a table and then search the table each time we load a
module to see if the module's digest is in it.

> The firmware key database would have to be mutable.  That allows adding
> arbitrary keys at any time.

What have firmware keys got to do with it?  This particular point is about
module signatures.  Possibly it should've been in a separate discussion, but
it is related code.

> The global one key to rule them all trust model doesn't work for this.
> However, a certificate constraint setting the actual constraint properly
> would.

We can set constraints in X.509 certs easily enough.  The problem is getting
the vendor to do it right.  We could always supply them with a wrapper script
for openssl to do this.

> The current MS policy is hashes only, but dbx can have keys as well.

How do you have a key in the blacklist?  Do you put the public key data in
there?  I'm not clear on this.

> > However, we could also have a list of SHA256 hashes and names in the
> > linux-firmware package with its own signature that we can demand load using
> > request_firmware().
> 
> That means no firmware update without kernel update ... why not just
> build the firmware in in that case?

No it doesn't.  That's why the list has a signature.  The kernel checks the
signature against a key it has.  This means that there can be many versions of
the list each with its own signature, but a kernel only needs one key.

> I mean you can have n files each with one signature, even if the format
> didn't support n signatures in one file ... essentially rendering the
> problem irrelevant.

What problem?  I'm not sure what you're referring to.  You're arguing with
supplementary information.

> X509 already solved this.

Yes.

> The authority key identifier explains how to encode trust of a public key.

Not completely.

You've missed a bit.  The AKID alone is insufficient to validate a cert
against its 'parent'.  You also have to have a cryptographic piece to do the
actual validation - in this case the signature on the cert.

If the driver only supplies an AKID, that is *not* sufficient because you can
trivially switch crypto data whilst keeping the SKID in an X.509 cert the
same.  You cannot validate a cert's SKID against its own public key because
there's no single defined method of generating it.

My point is that a driver cannot specify an AKID alone to select the cert to
verify its firmware.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Peter Jones <pjones@redhat.com> wrote:

> And even past there - if the firmware update is compliant with NIST
> SP800-147 (which they really all /should/ be, but we know how that
> goes), then the actual blob that gets passed to the firmware still must
> be signed with a key trusted by the firmware.

This is just BIOS updating, right, and not, say, for supplying firmware to my
DVB cards?

Though I suppose the technique might be generally applicable.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

josh@joshtriplett.org wrote:

> What's the advantage to using signatures here, rather than hashes?
> 
> What if we just made request_firmware take a cryptographically secure
> hash, and verify that the firmware supplied by userspace has that hash?
> Ideally, different firmware should have a different version, and often
> the kernel driver knows the specific versions it works with.
> 
> The main advantage of signatures would be the ability to update the
> firmware *without* updating the driver.  Is that a feature?  Is it
> really a problem to add a hash to the driver?

If you wanted to update *any* piece of firmware, you would have to update your
kernel.  Further, you'd have to keep a back catalogue of *all* the old
firmware versions that your device might support.

Further, there was a mismatch between the release of the linux-firmware
package, say, and the kernel such that the firmware was installed first, you
might render a whole load of users' systems unbootable - or, at least,
distinctly degraded in operation.  That could get lawyers involved;-)

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
> 
> This will require that we take any firmware vendor's key and rewrap it
> somehow into a new X.509 blob with a key usage constraint.

There are established ways of handling those constraints as external
objects (see how NSS does it in its trust tokens, and thus p11-kit
-trust does too).

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 11:36 -0700, josh@joshtriplett.org wrote:
> 
> The main advantage of signatures would be the ability to update the
> firmware *without* updating the driver.  Is that a feature?

Yes, absolutely. We do want to be able to update firmware *without*
updating the driver. They are separate entities.

That said, some drivers whose firmware is *actually* never updated and
is only separate for licensing and unswappable-kernel-data-size reasons
*could* perhaps just use a hash.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
>>
>> This will require that we take any firmware vendor's key and rewrap it
>> somehow into a new X.509 blob with a key usage constraint.
>
> There are established ways of handling those constraints as external
> objects (see how NSS does it in its trust tokens, and thus p11-kit
> -trust does too).

Wow, I thought X.509 was bad.  Now we get PKCS#11, too?  Ick.

I have no problem whatsoever with having the userspace tooling support
PKCS#11 tokens.  I think the kernel should try to minimize the extent
to which is depends on X.509 on the kernel side.

If we're going to load keys into the kernel (at compile time, from
UEFI, whatever), let's just *tell* the kernel, in plain English or C,
what those keys are for, rather than trying to parse X.509
constraints.

I'll point out that the Internet tried to use X.509 name constraints
to allow CAs to be constrained to subsets of the DNS space, and it
*still* doesn't work.

Heck, with the X.509 variant, if Megasoft has an existing key signed
by SketchyTrust, and we want to trust SketchyTrust to sign firmware
for SketchyUSB devices (and to delegate to Megasoft using the
*existing* key), are we supposed to enforce transitive constraints?
Where are they rooted?  I think this way lies madness.  Let's just
throw SketchyTrust's key in the "SketchyUSB only" pile and be done
with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's
self-signed (?).

If I'm the unaffiliated author of a driver for a SketchyTrust device,
I want to throw the cert into my driver and be done with it.  The
kernel should *figure out on its own* that the cert is associated with
my driver and my driver only and can't sign for my GPU.  I really
don't want to muck with the X.509 blob, because I'm going to get it
wrong.

[1] If we start rewrapping root keys and shoving the X.509 blobs into
drivers, who signs those blobs?  We can't self-sign them because we
don't have the private key, and we don't really want a completely
pointless "kernel" key that exists solely for the purpose of producing
well-formed X.509 certs, and we probably don't want to use ill-formed
unsigned X.509 certs as our root.  So what's the point of using X.509
at all for this purpose?

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Luis R. Rodriguez]

On Tue, Jul 28, 2015 at 08:11:36PM +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > If we start signing
> > stuff we're not sure should be trusted that explodes the whole model.
> > Therefore, you need to establish two things
> > 
> >      1. What is it that we actually trust?  (I think it's the
> >         transmission path from the firmware supplier, but you haven't
> >         said)

This is the only thing this can help with now, *and* since it comes from there
that it respects obviously linux-firmware license requirements ;)

> I acknowledge this is a tricky point.  Currently, we don't have signatures
> from vendors that we can use.  What we have is blobs either grabbed from
> websites, extracted from Windows installations or provided by the vendor
> directly.  Basically, we cannot trust *anything* we have at the moment.

At least on the 802.11 world I did experience tons of direct vendor involvement
in submitting firmware upstream directly. So this varies by subsystem. I suspect
Nvidia won't participate for their latest GPUs... But fuck 'em anyway right?

> >      2. If we can't validate 1, what do we do
> 
> We need a fallback option.  Possibly one that can be enabled/disabled from the
> kernel command line that allows firmware blobs with signatures set by the
> linux-firmware maintainer indicating this is, to our best knowledge, a valid
> blob.  However, that does raise the issue of how you rescind that indication.

As with module signing I think CONFIG_FIRMWARE_SIG_FORCE=y should only be used
for FW for folks who know who can vet all firmware and want this, the
permissive option you describe I think would be for folks who do not enable
CONFIG_FIRMWARE_SIG_FORCE. There's more to this though, as I'll describe
below.

> > For 2. I think you need to leave stuff you can't validate 1. for
> > unsigned and let system policy decide.  Signing is implying a trust you
> > don't have and thus corrupting the trust model.
> 
> That's a fair point.
> 
> I guess what you want is:
> 
>  (1) A driver can provide a key in some fashion (exact mechanism TBD), then we
>      only permit firmware signed by that key.
> 
>  (2) If driver provides a key but the firmware doesn't have an associated
>      signature, we reject it.

The second set of patches that I have enable this as this criteria is exactly
what I wanted to enable to replace CRDA in userspace. It would also make it
separate from FW signing, so although CONFIG_FIRMWARE_SIG_FORCE=n a driver
can still have a Kconfig option for its own use which may let folks require
or not signing for its driver.

>  (3) A driver can provide a hash of the firmware content and only that exact
>      firmware blob is permitted (or possibly a list of alternative hashes).

The firmware API keeps being abused, my second set of patches make the
firmware API extensible to enable such features if we really want them.

The way to think about it is we'd expose an API to let users use
sysdata_file_request() or sysdata_file_request_async() and on it they'd
pass a const struc sysdata_file_desc (descriptor) which provides all the
requirements. Interally then the kernel sees if it can match it and if so
it tosses the system data file (I call it this now as its not just firmware
we'd be using this for) to the caller.

All sysdata_file_request*() API users would need an OID registered too
so that a key can only be used for that purpose.

>  (4) If a driver doesn't provide a key, we always accept the firmware.
> 
> Which means that someone can use firmware for a driver that falls into
> category (4) as an attack mechanism.  Ideally, I'd like to close (4)
> entirely.  We could instead:
> 
>  (4) If the firmware is signed by the linux-firmware key, we log a warning but
>      accept the firmware.
> 
>  (5) We reject the firmware.

The way I have it now if usres use sysdata_file_request*() APIs then only
the criteria there must be met but if we wanted to piggy back off support
for Kyle's key we can easily do that with a flag, but by default I didn't
support this. ie, if you wanted to trust Kyle's key you'd just use the
old firmware_request() APIs with CONFIG_FIRMWARE_SIG=y, but we can change
this of course.

  Luis

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 12:31 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
> > > 
> > > This will require that we take any firmware vendor's key and rewrap it
> > > somehow into a new X.509 blob with a key usage constraint.
> > 
> > There are established ways of handling those constraints as external
> > objects (see how NSS does it in its trust tokens, and thus p11-kit
> > -trust does too).
> 
> Wow, I thought X.509 was bad.  Now we get PKCS#11, too?  Ick.

$DEITY no, we don't need that in the kernel (although I'm seriously
looking at a PKCS#11 module in userspace which interacts with the
kernel keyring).

I was merely pointing out that there are established methods of
matching *separate* trust objects (including non-standard usage fields)
with existing X.509 certificates. Which *don't* involve needing to
'rewrap it somehow into a new X.509 blob with a key usage constraint'.

> Heck, with the X.509 variant, if Megasoft has an existing key signed
> by SketchyTrust, and we want to trust SketchyTrust to sign firmware
> for SketchyUSB devices (and to delegate to Megasoft using the
> *existing* key), are we supposed to enforce transitive constraints?
> Where are they rooted?  I think this way lies madness.  Let's just
> throw SketchyTrust's key in the "SketchyUSB only" pile and be done
> with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's
> self-signed (?).

Yes, absolutely. That's what I've been saying all along. It's an extra
argument to the request_firmware() call.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Peter Jones]

On Tue, Jul 28, 2015 at 08:14:09PM +0100, David Howells wrote:
> Peter Jones <pjones@redhat.com> wrote:
> 
> > And even past there - if the firmware update is compliant with NIST
> > SP800-147 (which they really all /should/ be, but we know how that
> > goes), then the actual blob that gets passed to the firmware still must
> > be signed with a key trusted by the firmware.
> 
> This is just BIOS updating, right, and not, say, for supplying firmware to my
> DVB cards?
> 
> Though I suppose the technique might be generally applicable.

It singles out system firmware quite a bit, yes, though it isn't clear
to me that you /couldn't/ read it against updates for a PCI Option ROM
or even the binary we upload to a running card for wifi if you chose to
implement your hardware that way.

Additionally, if you're on a modernish UEFI system:

a) the "Capsule Update" mechanism we're using for firmware updates can
be used on option roms, and it can validate them first and return
EFI_SECURITY_VIOLATION to us if they don't validate, and
b) UEFI Option ROMs are just PE binaries, and if Secure Boot is enabled,
if they don't verify correctly against the SB databases, they don't get
loaded and run.

So there are multiple layers of protection there.

-- 
        Peter

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Greg KH]

On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> > So in that case, what's the advantage of separating the firmware from
> > the driver?  If we can't update it without updating the driver, we could
> > just build it in and save a huge amount of hassle.
> 
> Licensing, which is a large part of why we have request_firmware to
> begin with.  Let's not make distribution kernel maintainers' lives more
> difficult than they already are.

Not true at all, please talk with some lawyers about this.

Or, to be clear, the lawyers I have discussed this with have no issues
at all with it.  Yours might differ.  Insert joke about 2 lawyers and 3
opinions and all that...

thanks,

greg k-h

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 20:11 +0100, David Howells wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > > (1b) Assuming we want to reject any firmware blob for which we don't have a
> > >      valid signature, what do we do about things for which we don't have a
> > >      signature?
> > > 
> > > I'm assuming that we reasonably regard the set of blobs in linux-firmware -
> > > and for the moment we might have to sign them all with the linux-firmware
> > > manager's key.  Now this might be a bad assumption, but we can't practically
> > > say that we require *every* firmware vendor to give us a signature for every
> > > blob before we can guarantee that all of them will work.
> > 
> > We can make it optional.  The driver already encodes for the firmware
> > location and version, if it uses request_firmware, it can easily add a
> > signing key field.
> 
> Optional, as in the driver decides whether to use the facility?  or optional
> as in we only check the signature if it is present and allow the firmware if
> there's no signature?

If there's no signature, that depends on current policy as supplied by
the user.

> > > > >  (3) If the vendors of firmware blobs supply signatures, should we
> > > > >      accept those instead of or as well as linux-firmware signatures?
> > > > 
> > > > Of course, How are you going to validate other than by trusting the
> > > > vendor?  Conversely, if you don't trust the vendor, why are you loading
> > > > an unknown binary blob from them into a processing engine they made?
> > > 
> > > As previously mentioned, we have to deal with as-yet unsigned firmware
> > > blobs or the validation can be worked around by simple removing the
> > > signature file.
> > 
> > Look, you're implying signed == trusted, right?
> 
> Not entirely.  Built-in is trusted implicitly.  But we need to go from what we
> have built in.
> 
> Now, we can decide that we're happy with either building an X.509 cert into a
> driver or just a sha256 sum and using that to autoload the cert on a temporary
> basis.  But we're going from built-in data.
> 
> > If we start signing
> > stuff we're not sure should be trusted that explodes the whole model.
> > Therefore, you need to establish two things
> > 
> >      1. What is it that we actually trust?  (I think it's the
> >         transmission path from the firmware supplier, but you haven't
> >         said)
> 
> I acknowledge this is a tricky point.  Currently, we don't have signatures
> from vendors that we can use.  What we have is blobs either grabbed from
> websites, extracted from Windows installations or provided by the vendor
> directly.  Basically, we cannot trust *anything* we have at the moment.
> 
> >      2. If we can't validate 1, what do we do
> 
> We need a fallback option.  Possibly one that can be enabled/disabled from the
> kernel command line that allows firmware blobs with signatures set by the
> linux-firmware maintainer indicating this is, to our best knowledge, a valid
> blob.  However, that does raise the issue of how you rescind that indication.
> 
> > For 2. I think you need to leave stuff you can't validate 1. for
> > unsigned and let system policy decide.  Signing is implying a trust you
> > don't have and thus corrupting the trust model.
> 
> That's a fair point.
> 
> I guess what you want is:
> 
>  (1) A driver can provide a key in some fashion (exact mechanism TBD), then we
>      only permit firmware signed by that key.

Right ... I'm assuming signed drivers have to be part of this?  So
validating the key within the driver is assumed to have been done by
whoever built the kernel.

>  (2) If driver provides a key but the firmware doesn't have an associated
>      signature, we reject it.

The driver should have a policy recommendation along with the key:
Require signing or follow system policy.  This would allow for a
transition period with mixed signed/unsigned firmware.

>  (3) A driver can provide a hash of the firmware content and only that exact
>      firmware blob is permitted (or possibly a list of alternative hashes).

Yes.

>  (4) If a driver doesn't provide a key, we always accept the firmware.

No, we follow system policy.  If the system policy is no unsigned
firmware, then the driver fails to load.  If policy says 

> Which means that someone can use firmware for a driver that falls into
> category (4) as an attack mechanism.  Ideally, I'd like to close (4)
> entirely.  We could instead:
> 
>  (4) If the firmware is signed by the linux-firmware key, we log a warning but
>      accept the firmware.
> 
>  (5) We reject the firmware.
> 
> Now, if we want to load keys from a userspace store by hash, we can have
> request_key() do that simply enough.
> 
> Is it possible for someone to fabricate a key pair that has a specific public
> key but a random private key?  I think from the maths it's impractical in
> useful time.

You're asking if it's possible to subvert the entire basis for our
current PKI schemes? ... I really hope not.  To generate a private key,
you'd either have to be incredibly lucky, be able to factor the modulus
or take a discrete logarithm, the latter two are still unsolved (in
reasonable time) mathematical problems.

> > In the real world, what vendor would be willing to admit their private
> > key is compromised ... do you know the amount of trouble that would
> > cause with their trust for other things, like UEFI ...
> 
> Microsoft might kill their key through a UEFI blacklist if it allows someone
> to break into Windows.
> 
> > > > >  (6) Should module signatures contain the module name - to be matched
> > > > >      against the modinfo structure after the signature is checked?
> > > > 
> > > > I'm agnostic on this, but if we're doing signatures, we already have the
> > > > sha256 of the code.  We can build a simple comparison table, so we can
> > > > match to the signature without knowing the name.
> > > 
> > > It would have to be built into the core kernel.  The Fedora kernel I'm
> > > running has 4118 modules available.  That's 32 bytes per module, assuming
> > > simply a flat list of module digests - giving a total table size of ~128K
> > > of uncompressible, unswappable data.  Further, you also cannot load any
> > > module external to that set - so no OpenAFS, no
> > 
> > Why not? ... you seem to have some model in your head that you haven't
> > fully elucidated, could you share.
> 
> If you have a 'simple comparison table' then presumably you have to reject
> anything not in the table - otherwise what's the point having the table?
> 
> I'm assuming you're thinking that we gather digests of all 4118 modules, cat
> them together into a table and then search the table each time we load a
> module to see if the module's digest is in it.

Um, wouldn't the hash be in the module ... and the module is validated
at load time by whatever kernel mechanism we're using.

> > The firmware key database would have to be mutable.  That allows adding
> > arbitrary keys at any time.
> 
> What have firmware keys got to do with it?  This particular point is about
> module signatures.  Possibly it should've been in a separate discussion, but
> it is related code.

OK, now I'm confused ... I was assuming based on what happened in 2012
at the Kernel Summit that signed modules is an agreed reality, so I was
presuming this was an extension scheme for signed firmware.  We can thus
take it that anything in a module is validated.

> > The global one key to rule them all trust model doesn't work for this.
> > However, a certificate constraint setting the actual constraint properly
> > would.
> 
> We can set constraints in X.509 certs easily enough.  The problem is getting
> the vendor to do it right.  We could always supply them with a wrapper script
> for openssl to do this.
> 
> > The current MS policy is hashes only, but dbx can have keys as well.
> 
> How do you have a key in the blacklist?  Do you put the public key data in
> there?  I'm not clear on this.

A key can be added either its full public key part of the certificate.
Um, other mechanisms are under discussion and may be published ... I'll
have to check what's actually public before answering more fully.

> > > However, we could also have a list of SHA256 hashes and names in the
> > > linux-firmware package with its own signature that we can demand load using
> > > request_firmware().
> > 
> > That means no firmware update without kernel update ... why not just
> > build the firmware in in that case?
> 
> No it doesn't.  That's why the list has a signature.  The kernel checks the
> signature against a key it has.  This means that there can be many versions of
> the list each with its own signature, but a kernel only needs one key.

I'm confused ... signed by what?  A digital signature is simply an
encrypted hash.  The key that encrypts the hash is the signing key and
the hash identifies some blob of data that is now signed.

> > I mean you can have n files each with one signature, even if the format
> > didn't support n signatures in one file ... essentially rendering the
> > problem irrelevant.
> 
> What problem?  I'm not sure what you're referring to.  You're arguing with
> supplementary information.

OK, I think we're talking past each other.

> > X509 already solved this.
> 
> Yes.
> 
> > The authority key identifier explains how to encode trust of a public key.
> 
> Not completely.
> 
> You've missed a bit.  The AKID alone is insufficient to validate a cert
> against its 'parent'.  You also have to have a cryptographic piece to do the
> actual validation - in this case the signature on the cert.

Right, that's why I said X509 solved it.

> If the driver only supplies an AKID, that is *not* sufficient because you can
> trivially switch crypto data whilst keeping the SKID in an X.509 cert the
> same.  You cannot validate a cert's SKID against its own public key because
> there's no single defined method of generating it.

What problem are you trying to solve?  An X509 cert is signed by the
parent.  You can't swap data without the signature going invalid.  The
TBS data only has the subject ID, true, but the authenticated
attributes, which have the IDs cannot be altered without rendering the
signature invalid.  For a self signed certificate, you can do this, but
they're only used for CA roots.

> My point is that a driver cannot specify an AKID alone to select the cert to
> verify its firmware.

OK, I still don't understand why.  If we can specify a key or a hash,
why not an KID, which is simply a hash of a public key?

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Tue, 2015-07-28 at 12:31 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 12:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Tue, 2015-07-28 at 10:03 -0700, Andy Lutomirski wrote:
> >>
> >> This will require that we take any firmware vendor's key and rewrap it
> >> somehow into a new X.509 blob with a key usage constraint.
> >
> > There are established ways of handling those constraints as external
> > objects (see how NSS does it in its trust tokens, and thus p11-kit
> > -trust does too).
> 
> Wow, I thought X.509 was bad.  Now we get PKCS#11, too?  Ick.
> 
> I have no problem whatsoever with having the userspace tooling support
> PKCS#11 tokens.  I think the kernel should try to minimize the extent
> to which is depends on X.509 on the kernel side.
> 
> If we're going to load keys into the kernel (at compile time, from
> UEFI, whatever), let's just *tell* the kernel, in plain English or C,
> what those keys are for, rather than trying to parse X.509
> constraints.
> 
> I'll point out that the Internet tried to use X.509 name constraints
> to allow CAs to be constrained to subsets of the DNS space, and it
> *still* doesn't work.
> 
> Heck, with the X.509 variant, if Megasoft has an existing key signed
> by SketchyTrust, and we want to trust SketchyTrust to sign firmware
> for SketchyUSB devices (and to delegate to Megasoft using the
> *existing* key), are we supposed to enforce transitive constraints?
> Where are they rooted?  I think this way lies madness.  Let's just
> throw SketchyTrust's key in the "SketchyUSB only" pile and be done
> with it rather than fiddling with OpenSSL to re-wrap SketchyTrust's
> self-signed (?).

I think you're making this too problematic.  There's two things:

     1. Root of trust for firmware keys.  I think having a X509 key with
        a firmware usage signing constraint is fine ... we just have to
        get a CA to issue those.  That would prevent the key from being
        a general trust key, which is useful
     2. Internal kernel policy for how we use the keys (this would not
        be coded in the cert) to say which key we trust for which
        driver.

1 is insufficient and trying to make 2 a general mechanism (or part of
the cert) is a path to madness.  Specifying specific firmware keys we
trust for specific drivers by the public key hash is fine (and actually
obviates 1 which is optional and just ensures that we don't get firmware
only keys into our general root key).  It's a simple per driver table, I
think.

James


> If I'm the unaffiliated author of a driver for a SketchyTrust device,
> I want to throw the cert into my driver and be done with it.  The
> kernel should *figure out on its own* that the cert is associated with
> my driver and my driver only and can't sign for my GPU.  I really
> don't want to muck with the X.509 blob, because I'm going to get it
> wrong.
> 
> [1] If we start rewrapping root keys and shoving the X.509 blobs into
> drivers, who signs those blobs?  We can't self-sign them because we
> don't have the private key, and we don't really want a completely
> pointless "kernel" key that exists solely for the purpose of producing
> well-formed X.509 certs, and we probably don't want to use ill-formed
> unsigned X.509 certs as our root.  So what's the point of using X.509
> at all for this purpose?
> 
> --Andy
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> Um, wouldn't the hash be in the module ... and the module is validated
> at load time by whatever kernel mechanism we're using.

I think we're talking at cross-purposes.  The point was:

    (6) Should module signatures contain the module name - to be matched
        against the modinfo structure after the signature is checked?

I'm asking about whether a *module* signature should be tied to the name of
the *module* it is signing.  Nothing to do with firmware.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Jul 28, 2015 at 3:39 PM, David Howells <dhowells@redhat.com> wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
>> Um, wouldn't the hash be in the module ... and the module is validated
>> at load time by whatever kernel mechanism we're using.
>
> I think we're talking at cross-purposes.  The point was:
>
>     (6) Should module signatures contain the module name - to be matched
>         against the modinfo structure after the signature is checked?
>
> I'm asking about whether a *module* signature should be tied to the name of
> the *module* it is signing.  Nothing to do with firmware.
>

I vote "no" because I can't see a threat model under which it matters.
If you can sign a module at all, then root can load it regardless of
what it's called.  Nonroot can't supply the module under a forged
name, regardless of whether the signature covers the name.

Kexec may be a different story.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[josh]

On Tue, Jul 28, 2015 at 02:38:05PM -0700, Greg KH wrote:
> On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> > > So in that case, what's the advantage of separating the firmware from
> > > the driver?  If we can't update it without updating the driver, we could
> > > just build it in and save a huge amount of hassle.
> > 
> > Licensing, which is a large part of why we have request_firmware to
> > begin with.  Let's not make distribution kernel maintainers' lives more
> > difficult than they already are.
> 
> Not true at all, please talk with some lawyers about this.

I didn't say anything about a license violation; I'm talking about
firmware licenses that aren't FOSS, which means distributions like
Debian "main" can't ship them.

- Josh Triplett

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Greg KH]

On Tue, Jul 28, 2015 at 04:59:26PM -0700, josh@joshtriplett.org wrote:
> On Tue, Jul 28, 2015 at 02:38:05PM -0700, Greg KH wrote:
> > On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> > > > So in that case, what's the advantage of separating the firmware from
> > > > the driver?  If we can't update it without updating the driver, we could
> > > > just build it in and save a huge amount of hassle.
> > > 
> > > Licensing, which is a large part of why we have request_firmware to
> > > begin with.  Let's not make distribution kernel maintainers' lives more
> > > difficult than they already are.
> > 
> > Not true at all, please talk with some lawyers about this.
> 
> I didn't say anything about a license violation; I'm talking about
> firmware licenses that aren't FOSS, which means distributions like
> Debian "main" can't ship them.

As the person who made the kernel in Debian "not-free" well over a
15 years ago because of some people "feeling" that you can't bundle a
binary image inside the kernel image, I strongly object to that opinion,
and consulted legal council on this very topic, as I stated.

If Debian, or other distros, wish to take a different legal stance,
wonderful, but again, this is up to them, but note that it is not such a
clear "licensing" issue as you might think.

If a company wants to have their firmware used on Linux, it is quite
easy for them to license it in a way that allows the binary to be
distributed.  And as you are wanting to get them to now sign the
firmware image, they must already wish to work with us to make that
happen, so I don't understand your objection here.

anyway, way off-topic, let's just drop it...

greg k-h

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Morris]

On Tue, 28 Jul 2015, Andy Lutomirski wrote:

> This does not mean that their key should be acceptable for kexec
> images, modules, GPU firmware, firmware for different vendors' USB
> sticks, firmware for my hard disk, etc.  In fact I flat out distrust
> them if they ever try to provide such blobs.

Limiting key use is generally a good idea, even if we trust the vendor, 
keys get stolen.  We want to limit the damage that can be done with those 
keys.


-- 
James Morris
<jmorris@namei.org>

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 11:54 -0700, josh@joshtriplett.org wrote:
> 
> For the drivers I'm most familiar with, new versions of firmware have
> new filenames and are requested from userspace in most-preferred to
> least-preferred order.  The expectation of those drivers is that any
> given firmware version should be binary-identical.

Those drivers are Doing It Wrong™.

The filename of a firmware image is intended to be like the soname of a
library.

If the firmware is ABI-compatible and just has some bugs fixed or
performance improvements, then you don't need to change the driver at
all. You just get the new version of the firmware and it all works.

Only if the driver *needs* to change the way it talks to the firmware,
should the filename change.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 15:44 -0700, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 3:39 PM, David Howells <dhowells@redhat.com> wrote:
> > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > > Um, wouldn't the hash be in the module ... and the module is validated
> > > at load time by whatever kernel mechanism we're using.
> > 
> > I think we're talking at cross-purposes.  The point was:
> > 
> >     (6) Should module signatures contain the module name - to be matched
> >         against the modinfo structure after the signature is checked?
> > 
> > I'm asking about whether a *module* signature should be tied to the name of
> > the *module* it is signing.  Nothing to do with firmware.
> > 
> 
> I vote "no" because I can't see a threat model under which it matters.
> If you can sign a module at all, then root can load it regardless of
> what it's called.  Nonroot can't supply the module under a forged
> name, regardless of whether the signature covers the name.

Right.

Including the module name in the signature *only* protects you against
an attacker who can provide a rogue module which *happens* to match the
digest of a genuine module.... but their rogue module has a different
name in the modinfo struct.

And quite frankly, if the attacker can manage that much, they'll manage
to get the name to match soon after. Meanwhile, I'll be in the bunker
because the world is about to end.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Tue, 2015-07-28 at 14:38 -0700, Greg KH wrote:
> On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> > > So in that case, what's the advantage of separating the firmware from
> > > the driver?  If we can't update it without updating the driver, we could
> > > just build it in and save a huge amount of hassle.
> > 
> > Licensing, which is a large part of why we have request_firmware to
> > begin with.  Let's not make distribution kernel maintainers' lives more
> > difficult than they already are.
> 
> Not true at all, please talk with some lawyers about this.
> 
> Or, to be clear, the lawyers I have discussed this with have no issues
> at all with it.  Yours might differ. 

Lawyers will mostly argue anything their client wants them to.

So that isn't data; it's barely even a relevant anecdote. It certainly
doesn't merit a blanket statement like 'not true at all'.

If anything, your anecdote tells us more about the desires of those who
were *paying* the lawyers in question, than it does about the matter at
hand.

Hell, *I* can find a doctor who will assert that vaccines cause autism,
if you want one¹. 

Something like this is not *truly* settled until/unless there is a
court ruling — and then only in that jurisdiction, and until/unless
it's appealed/overruled.

So yes, I'm sure there are lawyers who will turn up in court and argue
whatever it is that they need to argue to make that case — that a
kernel bzImage *isn't* a "work based on the [Linux kernel]", or that a
binary-only firmware image therein, which cannot be automatically
extracted or separated because it is static data within one of the C
files of a GPL'd driver, somehow *is* nevertheless "being distributed
as a separate work".

But there are other lawyers and expert witnesses who will respond to
those arguments with a resounding WTF.

Nobody gets to say "not true at all" before it's actually come to
court.

In the meantime, there are genuine licensing reasons why a risk-averse
company might elect *not* to build non-GPL firmware *into* a Linux
kernel image. Because they might not want to end up being summoned to
that court room, and might not want to have to pay that lawyer to make
that argument.

So Josh was entirely correct.

-- 
dwmw2

¹ He's in the basement. Just $20 and you can kick him in the balls.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Mark Brown]

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

On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> On Tue, Jul 28, 2015 at 11:44:21AM -0700, James Bottomley wrote:

> > So in that case, what's the advantage of separating the firmware from
> > the driver?  If we can't update it without updating the driver, we could
> > just build it in and save a huge amount of hassle.

> Licensing, which is a large part of why we have request_firmware to
> begin with.  Let's not make distribution kernel maintainers' lives more
> difficult than they already are.

Also developer convenience when people are working on the firmware
(which presumably isn't built as part of the kernel build process).

> For the drivers I'm most familiar with, new versions of firmware have
> new filenames and are requested from userspace in most-preferred to
> least-preferred order.  The expectation of those drivers is that any
> given firmware version should be binary-identical.

> Are there drivers for which the expected firmware update cycle is *more*
> rapid than the kernel release cycle?  That would be quite a surprise,
> though not an unpleasant one.

Some of the audio ones are like this, especially during development -
firmware is used to get system specific callibration data (to account
for the plastics and the taste of the system integator).  Those
firmwares would need system specific lists which would be miserable.

The code firmwares themselves do also get updated rather rapidly at
times.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Wed, 2015-07-29 at 12:57 +0100, Mark Brown wrote:
> > Are there drivers for which the expected firmware update cycle is *more*
> > rapid than the kernel release cycle?  That would be quite a surprise,
> > though not an unpleasant one.
> 
> Some of the audio ones are like this, especially during development -
> firmware is used to get system specific callibration data (to account
> for the plastics and the taste of the system integator).  Those
> firmwares would need system specific lists which would be miserable.
> 
> The code firmwares themselves do also get updated rather rapidly at
> times.

It's also not about "more rapid than the kernel release cycle", but
just about "not 100% strictly nailed to the kernel release cycle".

In some environments, the "kernel release cycle" is basically non
-existent. If you're running RHEL6, you get to remain with your ancient
kernel.

In a world where the driver requires a specific hashed firmware, they
are *not* going to update that driver unless there's a bloody good
reason to do so.

In a world where the firmware is *signed*, you can update it yourself
as long as the new version is also signed by an acceptable key.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Mark Brown]

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

On Wed, Jul 29, 2015 at 01:02:52PM +0100, David Woodhouse wrote:

> It's also not about "more rapid than the kernel release cycle", but
> just about "not 100% strictly nailed to the kernel release cycle".

Indeed, and that's the release cycle of the kernel that people are
running rather than the upstream kernel too.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

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

On Wed, 2015-07-29 at 10:37 +0100, David Woodhouse wrote:
> On Tue, 2015-07-28 at 14:38 -0700, Greg KH wrote:
> > On Tue, Jul 28, 2015 at 11:54:28AM -0700, josh@joshtriplett.org wrote:
> > > > So in that case, what's the advantage of separating the firmware from
> > > > the driver?  If we can't update it without updating the driver, we could
> > > > just build it in and save a huge amount of hassle.
> > > 
> > > Licensing, which is a large part of why we have request_firmware to
> > > begin with.  Let's not make distribution kernel maintainers' lives more
> > > difficult than they already are.
> > 
> > Not true at all, please talk with some lawyers about this.
> > 
> > Or, to be clear, the lawyers I have discussed this with have no issues
> > at all with it.  Yours might differ. 
> 
> Lawyers will mostly argue anything their client wants them to.
> 
> So that isn't data; it's barely even a relevant anecdote. It certainly
> doesn't merit a blanket statement like 'not true at all'.
> 
> If anything, your anecdote tells us more about the desires of those who
> were *paying* the lawyers in question, than it does about the matter at
> hand.
> 
> Hell, *I* can find a doctor who will assert that vaccines cause autism,
> if you want one¹. 

That's not even an opinion, it's wrong on the facts.  You can always
find a crackpot willing to argue by misrepresenting the facts, but it's
not what a reasonable person (or company) should base their decisions on
and not what we should do ... unless you want to open the door to say
re-doing our geo location libraries to take into account the views of
the flat-earth society?

> Something like this is not *truly* settled until/unless there is a
> court ruling — and then only in that jurisdiction, and until/unless
> it's appealed/overruled.
> 
> So yes, I'm sure there are lawyers who will turn up in court and argue
> whatever it is that they need to argue to make that case — that a
> kernel bzImage *isn't* a "work based on the [Linux kernel]", or that a
> binary-only firmware image therein, which cannot be automatically
> extracted or separated because it is static data within one of the C
> files of a GPL'd driver, somehow *is* nevertheless "being distributed
> as a separate work".
> 
> But there are other lawyers and expert witnesses who will respond to
> those arguments with a resounding WTF.
> 
> Nobody gets to say "not true at all" before it's actually come to
> court.
> 
> In the meantime, there are genuine licensing reasons why a risk-averse
> company might elect *not* to build non-GPL firmware *into* a Linux
> kernel image. Because they might not want to end up being summoned to
> that court room, and might not want to have to pay that lawyer to make
> that argument.

Really, no, there aren't.  Firmware is an operating system independent
blob which runs on a separate processor without modification for
Windows, Linux, Solaris or any other OS.  As such, there's no way it can
be considered a derived work of (or even based on) the Linux Kernel.
Thus it falls under the aggregation terms of clause 2 of the GPL:
        
        In addition, mere aggregation of another work not based on the
        Program with the Program (or with a work based on the Program)
        on a volume of a storage or distribution medium does not bring
        the other work under the scope of this License.

So it definitely doesn't have to be distributed under GPL and can be
aggregated with GPL components like Linux.

You're not out of the woods with this, though: the licence of the
firmware must permit arbitrary redistribution (and we've seen some that
don't), so it still has to be released under a freely redistributable
licence.  And, obviously, there's a greyer area for Linux Specific
firmware, but the above applies in the general case.

Distributions, like Debian, which have a definition for what they
consider to be "free software" may obviously conclude that binary blobs
don't satisfy that definition and therefore must be confined to the
non-free part of the distribution.  We can certainly continue to ship
firmware separately as a courtesy for Debian to prevent the hardship of
having to banish the whole kernel to non-free, but it's not because
there's any shadow of a doubt about the legality of aggregating Linux
independent firmware with the Linux Kernel.

James


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Wed, 2015-07-29 at 08:00 -0700, James Bottomley wrote:
> 
> 
> Really, no, there aren't.  Firmware is an operating system independent
> blob which runs on a separate processor without modification for
> Windows, Linux, Solaris or any other OS.  As such, there's no way it can
> be considered a derived work of (or even based on) the Linux Kernel.
> This...

I don't ever think anyone would claim that the firmware is a derived
work of the Linux kernel. Or that it is based on the Linux kernel.

That's a straw man. But it's also not really necessary for the point
you were making, which might as well start here:

> ...it falls under the aggregation terms of clause 2 of the GPL:
>         
>         In addition, mere aggregation of another work not based on the
>         Program with the Program (or with a work based on the Program)
>         on a volume of a storage or distribution medium does not bring
>         the other work under the scope of this License.
> 
> So it definitely doesn't have to be distributed under GPL and can be
> aggregated with GPL components like Linux.

I understand that opinion. But the whole 'mere aggregation on a volume
of a storage or distribution medium' thing is fairly ambiguous, and
there is plenty of scope for interpretation.

Certainly it seems intended to cover at *least* the case of things like
the old "shareware CDs", allowing GPL'd software to be included on
those as well as non-GPL'd software. Those are collective works, and
without the exception *would* have been prohibited by the GPL. (Again,
just in terms of what you are permitted to do with the GPL'd thing,
without ever making the bizarre claim that the non-GPL'd parts are in
any way derivative of or based on the GPL'd parts.)


It's possible to interpret that same clause as negating the *entirety*
of the paragraphs that precede it — permitting *any* combination of GPL
and non-GPL works as long as you call it 'aggregation' — and ignoring
the ill-defined word 'mere' that precedes it, and the context 'on a
volume of a storage or distribution medium' that follows.

One could then argue that even linking a proprietary piece of native
code into a GPL'd work and calling it directly is permitted — it's
still merely aggregation. Obviously, that doesn't seem like a
*reasonable* interpretation, as it would clearly make the licence
inconsistent with itself. So I wouldn't bet on a court backing that
interpretation — but then again, courts have done stupider things.

Then there's a whole spectrum of other possibilities, between the
minimal 'allow GPL'd stuff to appear on shareware CDs' to the excessive
'allow anything as long as you call it aggregation' interpretations
that I have outlined.

Your viewpoint, while a valid opinion, falls closer to the latter end
of that spectrum than mine does.

The fact remains that there is scope for reasonable people to disagree,
that *none* of us are right until it's tested, and there *is* a reason
for cautious people to err on the side of caution.


You make a point about Linux-specific firmware being a 'greyer area',
which is true precisely *because* of the ambiguity here. That, along
with many other factors, would affect a court's perception of whether
the the two parts are indeed 'merely aggregated on a volume of a
storage or distribution medium', or whether they are tied together as a
coherent 'whole which is based in part on the [kernel]'. 


I'm not going to tell you that your opinion on the 'mere aggregation on
a volume of a storage or distribution medium' thing is wrong, although
I happen to disagree with it.

But I *am* telling you that you are wrong to claim that there is *no*
risk. And that Greg is similarly wrong to make his absolute 'not true
at all' claim.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Josh Triplett]

On Wed, Jul 29, 2015 at 08:00:00AM -0700, James Bottomley wrote:
> You're not out of the woods with this, though: the licence of the
> firmware must permit arbitrary redistribution (and we've seen some that
> don't), so it still has to be released under a freely redistributable
> licence.  And, obviously, there's a greyer area for Linux Specific
> firmware, but the above applies in the general case.
> 
> Distributions, like Debian, which have a definition for what they
> consider to be "free software" may obviously conclude that binary blobs
> don't satisfy that definition and therefore must be confined to the
> non-free part of the distribution.  We can certainly continue to ship
> firmware separately as a courtesy for Debian to prevent the hardship of
> having to banish the whole kernel to non-free

(Or filter out the blobs.)

For the record, this point (that firmware *itself* is not Free Software)
was the only one I meant when I gave "licensing" as a reason to not
compile in firmware.  Feel free to continue the argument about the
legality of a bzImage containing firmware blobs if you like, but that's
not the point I was making.

- Josh triplett

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

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

On Wed, 2015-07-29 at 16:35 +0100, David Woodhouse wrote:
> On Wed, 2015-07-29 at 08:00 -0700, James Bottomley wrote:
> > 
> > 
> > Really, no, there aren't.  Firmware is an operating system independent
> > blob which runs on a separate processor without modification for
> > Windows, Linux, Solaris or any other OS.  As such, there's no way it can
> > be considered a derived work of (or even based on) the Linux Kernel.
> > This...
> 
> I don't ever think anyone would claim that the firmware is a derived
> work of the Linux kernel. Or that it is based on the Linux kernel.

OK, got that.

> That's a straw man. But it's also not really necessary for the point
> you were making, which might as well start here:
> 
> > ...it falls under the aggregation terms of clause 2 of the GPL:
> >         
> >         In addition, mere aggregation of another work not based on the
> >         Program with the Program (or with a work based on the Program)
> >         on a volume of a storage or distribution medium does not bring
> >         the other work under the scope of this License.
> > 
> > So it definitely doesn't have to be distributed under GPL and can be
> > aggregated with GPL components like Linux.
> 
> I understand that opinion. But the whole 'mere aggregation on a volume
> of a storage or distribution medium' thing is fairly ambiguous, and
> there is plenty of scope for interpretation.

No, it's not, you missed quoting the part that defines it.  It
specifically applies to aggregates of additional components which are
*not* based on the work.  The exact legal test for applying this
paragraph to a component is "not based on the work".

> Certainly it seems intended to cover at *least* the case of things like
> the old "shareware CDs", allowing GPL'd software to be included on
> those as well as non-GPL'd software. Those are collective works, and
> without the exception *would* have been prohibited by the GPL. (Again,
> just in terms of what you are permitted to do with the GPL'd thing,
> without ever making the bizarre claim that the non-GPL'd parts are in
> any way derivative of or based on the GPL'd parts.)
> 
> 
> It's possible to interpret that same clause as negating the *entirety*
> of the paragraphs that precede it — permitting *any* combination of GPL
> and non-GPL works as long as you call it 'aggregation' — and ignoring
> the ill-defined word 'mere' that precedes it, and the context 'on a
> volume of a storage or distribution medium' that follows.

No, the GPL relies on a specific copyright mechanism to apply to an
aggregated work, see below.

> One could then argue that even linking a proprietary piece of native
> code into a GPL'd work and calling it directly is permitted — it's
> still merely aggregation. Obviously, that doesn't seem like a
> *reasonable* interpretation, as it would clearly make the licence
> inconsistent with itself. So I wouldn't bet on a court backing that
> interpretation — but then again, courts have done stupider things.

No you can't.  Whether the aggregate paragraph I quoted applies is very
specific in legal terms.  It only applies to the combination of the work
with something which is not a derivative of the work.

> Then there's a whole spectrum of other possibilities, between the
> minimal 'allow GPL'd stuff to appear on shareware CDs' to the excessive
> 'allow anything as long as you call it aggregation' interpretations
> that I have outlined.

Well aggregate has a very specific legal meaning:

        AGGREGATE: A collection of particular persons or items, formed
        into one body

the mere act of aggregation does not constitute making a derivative
work.  We have to make other additional legal arguments if we want to
claim the aggregation is also a derivative.

> Your viewpoint, while a valid opinion, falls closer to the latter end
> of that spectrum than mine does.
> 
> The fact remains that there is scope for reasonable people to disagree,
> that *none* of us are right until it's tested, and there *is* a reason
> for cautious people to err on the side of caution.

No, the paragraph is clear and has a well defined legal test: Unless you
can opine that the component you're aggregating is *also* based on the
work, the clause I quoted applies and the aggregation is allowed without
the component having to be under GPL.

> You make a point about Linux-specific firmware being a 'greyer area',
> which is true precisely *because* of the ambiguity here. That, along
> with many other factors, would affect a court's perception of whether
> the the two parts are indeed 'merely aggregated on a volume of a
> storage or distribution medium', or whether they are tied together as a
> coherent 'whole which is based in part on the [kernel]'. 
> 
> 
> I'm not going to tell you that your opinion on the 'mere aggregation on
> a volume of a storage or distribution medium' thing is wrong, although
> I happen to disagree with it.
> 
> But I *am* telling you that you are wrong to claim that there is *no*
> risk. And that Greg is similarly wrong to make his absolute 'not true
> at all' claim.

Really, no, the GPL is very carefully written to follow the tenets of
copyright law and specifically and deliberately never defines what
constitutes a derivative work because it relies on case law to do that.
This means the copyleft capture applies only to something which in legal
terms is a derivative of the work.  An aggregate may or may not be a
derivative work, but the mere act of aggregation does not create a
derivative (and there is definite case law on this), you have to apply
additional arguments to determine if an aggregate is also a derived
work.  You already agreed that most firmware is not a derived work of
the kernel, ipso facto, it's an aggregate which is not based on the work
and thus falls under the clause I quoted.  That's why this clause
exactly says "aggregation of another work not based on the Program".

Binary modules may fall under the GPL because there's an untested legal
argument based on more than mere aggregation that they are derived works
of the kernel.  Unless you can make some argument for why a piece
firmware is a derived work of the kernel, the aggregation paragraph
applies because it passes the "not based on the work" test and thus it
does not fall under the GPL.

James

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Wed, 2015-07-29 at 09:38 -0700, James Bottomley wrote:
> No, the paragraph is clear and has a well defined legal test: Unless you
> can opine that the component you're aggregating is *also* based on the
> work, the clause I quoted applies and the aggregation is allowed without
> the component having to be under GPL.

OK, so your opinion is indeed *right* at the very end of the spectrum I
described — you do actually believe that it directly contradicts all
the previous verbiage which explicitly states that it *does* apply to
combinations of GPL'd work with work that is "not derived from the
Program, and can be reasonably considered independent and separate
works in themselves."

> Really, no, the GPL is very carefully written to follow the tenets of
> copyright law and specifically and deliberately never defines what
> constitutes a derivative work because it relies on case law to do that.
> This means the copyleft capture applies only to something which in legal
> terms is a derivative of the work.  An aggregate may or may not be a
> derivative work, but the mere act of aggregation does not create a
> derivative (and there is definite case law on this), you have to apply
> additional arguments to determine if an aggregate is also a derived
> work. 

... as well as contradicting its explicit statement that its intention
is to "control the distribution of derivative OR COLLECTIVE WORKS".

That's fine, I'm *still* not going to tell you that you're wrong. As I
said, courts have made more bizarre decisions.

But there *is* scope for reasonable people to disagree with you. Let's
not pretend otherwise.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

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

On Wed, 2015-07-29 at 18:32 +0100, David Woodhouse wrote:
> On Wed, 2015-07-29 at 09:38 -0700, James Bottomley wrote:
> > No, the paragraph is clear and has a well defined legal test: Unless you
> > can opine that the component you're aggregating is *also* based on the
> > work, the clause I quoted applies and the aggregation is allowed without
> > the component having to be under GPL.
> 
> OK, so your opinion is indeed *right* at the very end of the spectrum I
> described — you do actually believe that it directly contradicts all
> the previous verbiage which explicitly states that it *does* apply to
> combinations of GPL'd work with work that is "not derived from the
> Program, and can be reasonably considered independent and separate
> works in themselves."
> 
> > Really, no, the GPL is very carefully written to follow the tenets of
> > copyright law and specifically and deliberately never defines what
> > constitutes a derivative work because it relies on case law to do that.
> > This means the copyleft capture applies only to something which in legal
> > terms is a derivative of the work.  An aggregate may or may not be a
> > derivative work, but the mere act of aggregation does not create a
> > derivative (and there is definite case law on this), you have to apply
> > additional arguments to determine if an aggregate is also a derived
> > work. 
> 
> ... as well as contradicting its explicit statement that its intention
> is to "control the distribution of derivative OR COLLECTIVE WORKS".

That quote loses the last important piece; that paragraph, which I'll
quote in full

        Thus, it is not the intent of this section to claim rights or
        contest your rights to work written entirely by you; rather, the
        intent is to exercise the right to control the distribution of
        derivative or collective works based on the Program.

says that no additional rights over pieces that were written by another
(in this case a firmware provider) and are not based on the Program are
claimed.  That rather supports the idea that the extent of the license
attachment is limited to derivation.

> That's fine, I'm *still* not going to tell you that you're wrong. As I
> said, courts have made more bizarre decisions.
> 
> But there *is* scope for reasonable people to disagree with you. Let's
> not pretend otherwise.

Well, I'll agree that if you'd quoted the paragraph before the one you
did, we'd have to split hairs over what is "the work" and what is "the
program" so perhaps it would be better to stop here.

James


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Wed, 2015-07-29 at 16:39 -0700, James Bottomley wrote:
> On Wed, 2015-07-29 at 18:32 +0100, David Woodhouse wrote:
> > ... as well as contradicting its explicit statement that its intention
> > is to "control the distribution of derivative OR COLLECTIVE WORKS".
> 
> That quote loses the last important piece; that paragraph, which I'll
> quote in full
> 
>         Thus, it is not the intent of this section to claim rights or
>         contest your rights to work written entirely by you; rather, the
>         intent is to exercise the right to control the distribution of
>         derivative or collective works based on the Program.
> 
> says that no additional rights over pieces that were written by another
> (in this case a firmware provider) and are not based on the Program are
> claimed.  That rather supports the idea that the extent of the license
> attachment is limited to derivation.

The more conventional interpretation of that paragraph — the
interpretation which *doesn't* require us to believe that the GPL
wasted all those words *explicitly* talking about things which are "not
derived from the Program, and can be reasonably considered independent
and separate works in themselves", only to contradict itself and say
"haha just joking; *ALL* aggregation is fine" — is that this is the GPL
clarifying how it operates within the constraints of copyright law.

There is a common — though bogus — complaint about the 'infectious'
nature of the GPL, which goes along the lines of "how can they require
that I publish the source code to the bits that *I* wrote. Copyright
law gives them no rights over *my* code".

The paragraph you cite above is more reasonably interpreted as a
clarification that the GPL isn't claiming any *rights* over your own
separate works, and that it merely operates by withholding permission
to use the *GPL'd* part in that context.

But again, I'm not requiring that you publicly accept this point of
view. There is plenty of scope for debate, and it's not impossible that
a court *could* uphold your interpretation and effectively just delete
the paragraphs of the GPL that you don't like.

All I'm asking is that you stop making the bogus claim that yours is
the *only* possible interpretation. It isn't even the sanest one.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

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

On Thu, 2015-07-30 at 09:08 +0100, David Woodhouse wrote:
> On Wed, 2015-07-29 at 16:39 -0700, James Bottomley wrote:
> > On Wed, 2015-07-29 at 18:32 +0100, David Woodhouse wrote:
> > > ... as well as contradicting its explicit statement that its intention
> > > is to "control the distribution of derivative OR COLLECTIVE WORKS".
> > 
> > That quote loses the last important piece; that paragraph, which I'll
> > quote in full
> > 
> >         Thus, it is not the intent of this section to claim rights or
> >         contest your rights to work written entirely by you; rather, the
> >         intent is to exercise the right to control the distribution of
> >         derivative or collective works based on the Program.
> > 
> > says that no additional rights over pieces that were written by another
> > (in this case a firmware provider) and are not based on the Program are
> > claimed.  That rather supports the idea that the extent of the license
> > attachment is limited to derivation.
> 
> The more conventional interpretation of that paragraph — the
> interpretation which *doesn't* require us to believe that the GPL
> wasted all those words *explicitly* talking about things which are "not
> derived from the Program, and can be reasonably considered independent
> and separate works in themselves", only to contradict itself and say
> "haha just joking; *ALL* aggregation is fine" — is that this is the GPL
> clarifying how it operates within the constraints of copyright law.
> 
> There is a common — though bogus — complaint about the 'infectious'
> nature of the GPL, which goes along the lines of "how can they require
> that I publish the source code to the bits that *I* wrote. Copyright
> law gives them no rights over *my* code".
> 
> The paragraph you cite above is more reasonably interpreted as a
> clarification that the GPL isn't claiming any *rights* over your own
> separate works, and that it merely operates by withholding permission
> to use the *GPL'd* part in that context.
> 
> But again, I'm not requiring that you publicly accept this point of
> view. There is plenty of scope for debate, and it's not impossible that
> a court *could* uphold your interpretation and effectively just delete
> the paragraphs of the GPL that you don't like.
> 
> All I'm asking is that you stop making the bogus claim that yours is
> the *only* possible interpretation. It isn't even the sanest one.

OK, let us suppose for the sake of argument that this is correct and the
GPL does manage to get extended to non derived included projects.  Even
in that case, we're not causing any corporate legal jeopardy because of
the principle of estoppel.  Estoppel says we cannot accuse someone of
breaching our licence for something we also did.  So if we ship the
firmware with the kernel, anyone else also shipping firmware with the
kernel is automatically innoculated against accusations of license
breach for that action.

James


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Heiko Stübner]

Am Donnerstag, 30. Juli 2015, 06:48:41 schrieb James Bottomley:
> On Thu, 2015-07-30 at 09:08 +0100, David Woodhouse wrote:
> > On Wed, 2015-07-29 at 16:39 -0700, James Bottomley wrote:
> > > On Wed, 2015-07-29 at 18:32 +0100, David Woodhouse wrote:
> > > > ... as well as contradicting its explicit statement that its intention
> > > > is to "control the distribution of derivative OR COLLECTIVE WORKS".
> > > 
> > > That quote loses the last important piece; that paragraph, which I'll
> > > quote in full
> > > 
> > >         Thus, it is not the intent of this section to claim rights or
> > >         contest your rights to work written entirely by you; rather, the
> > >         intent is to exercise the right to control the distribution of
> > >         derivative or collective works based on the Program.
> > > 
> > > says that no additional rights over pieces that were written by another
> > > (in this case a firmware provider) and are not based on the Program are
> > > claimed.  That rather supports the idea that the extent of the license
> > > attachment is limited to derivation.
> > 
> > The more conventional interpretation of that paragraph — the
> > interpretation which *doesn't* require us to believe that the GPL
> > wasted all those words *explicitly* talking about things which are "not
> > derived from the Program, and can be reasonably considered independent
> > and separate works in themselves", only to contradict itself and say
> > "haha just joking; *ALL* aggregation is fine" — is that this is the GPL
> > clarifying how it operates within the constraints of copyright law.
> > 
> > There is a common — though bogus — complaint about the 'infectious'
> > nature of the GPL, which goes along the lines of "how can they require
> > that I publish the source code to the bits that *I* wrote. Copyright
> > law gives them no rights over *my* code".
> > 
> > The paragraph you cite above is more reasonably interpreted as a
> > clarification that the GPL isn't claiming any *rights* over your own
> > separate works, and that it merely operates by withholding permission
> > to use the *GPL'd* part in that context.
> > 
> > But again, I'm not requiring that you publicly accept this point of
> > view. There is plenty of scope for debate, and it's not impossible that
> > a court *could* uphold your interpretation and effectively just delete
> > the paragraphs of the GPL that you don't like.
> > 
> > All I'm asking is that you stop making the bogus claim that yours is
> > the *only* possible interpretation. It isn't even the sanest one.
> 
> OK, let us suppose for the sake of argument that this is correct and the
> GPL does manage to get extended to non derived included projects.  Even
> in that case, we're not causing any corporate legal jeopardy because of
> the principle of estoppel. Estoppel says we cannot accuse someone of
> breaching our licence for something we also did.  So if we ship the
> firmware with the kernel, anyone else also shipping firmware with the
> kernel is automatically innoculated against accusations of license
> breach for that action.

Which may or may not be true in all jurisdictions. Aka in germany gpl 
violation suits most of the time take up device vendors, not the non-european 
soc vendor who violated the license originally.


Also what about the termination clause? According to [0] §4 says something 
along the lines of "Under v2, violators forfeit their rights to redistribute 
and modify the GPL’d software until those rights are explicitly reinstated by 
the copyright holder."

So while they may not be sued, they probably still also don't get the 
redistribution and modification rights?


[0] https://softwarefreedom.org/resources/2008/compliance-guide.html

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Thu, 2015-07-30 at 16:21 +0200, Heiko Stübner wrote:
> Am Donnerstag, 30. Juli 2015, 06:48:41 schrieb James Bottomley:
> > On Thu, 2015-07-30 at 09:08 +0100, David Woodhouse wrote:
> > > On Wed, 2015-07-29 at 16:39 -0700, James Bottomley wrote:
> > > > On Wed, 2015-07-29 at 18:32 +0100, David Woodhouse wrote:
> > > > > ... as well as contradicting its explicit statement that its intention
> > > > > is to "control the distribution of derivative OR COLLECTIVE WORKS".
> > > > 
> > > > That quote loses the last important piece; that paragraph, which I'll
> > > > quote in full
> > > > 
> > > >         Thus, it is not the intent of this section to claim rights or
> > > >         contest your rights to work written entirely by you; rather, the
> > > >         intent is to exercise the right to control the distribution of
> > > >         derivative or collective works based on the Program.
> > > > 
> > > > says that no additional rights over pieces that were written by another
> > > > (in this case a firmware provider) and are not based on the Program are
> > > > claimed.  That rather supports the idea that the extent of the license
> > > > attachment is limited to derivation.
> > > 
> > > The more conventional interpretation of that paragraph — the
> > > interpretation which *doesn't* require us to believe that the GPL
> > > wasted all those words *explicitly* talking about things which are "not
> > > derived from the Program, and can be reasonably considered independent
> > > and separate works in themselves", only to contradict itself and say
> > > "haha just joking; *ALL* aggregation is fine" — is that this is the GPL
> > > clarifying how it operates within the constraints of copyright law.
> > > 
> > > There is a common — though bogus — complaint about the 'infectious'
> > > nature of the GPL, which goes along the lines of "how can they require
> > > that I publish the source code to the bits that *I* wrote. Copyright
> > > law gives them no rights over *my* code".
> > > 
> > > The paragraph you cite above is more reasonably interpreted as a
> > > clarification that the GPL isn't claiming any *rights* over your own
> > > separate works, and that it merely operates by withholding permission
> > > to use the *GPL'd* part in that context.
> > > 
> > > But again, I'm not requiring that you publicly accept this point of
> > > view. There is plenty of scope for debate, and it's not impossible that
> > > a court *could* uphold your interpretation and effectively just delete
> > > the paragraphs of the GPL that you don't like.
> > > 
> > > All I'm asking is that you stop making the bogus claim that yours is
> > > the *only* possible interpretation. It isn't even the sanest one.
> > 
> > OK, let us suppose for the sake of argument that this is correct and the
> > GPL does manage to get extended to non derived included projects.  Even
> > in that case, we're not causing any corporate legal jeopardy because of
> > the principle of estoppel. Estoppel says we cannot accuse someone of
> > breaching our licence for something we also did.  So if we ship the
> > firmware with the kernel, anyone else also shipping firmware with the
> > kernel is automatically innoculated against accusations of license
> > breach for that action.
> 
> Which may or may not be true in all jurisdictions. Aka in germany gpl 
> violation suits most of the time take up device vendors, not the non-european 
> soc vendor who violated the license originally.

In German law, the principle of Estoppel mostly covered by the doctrine
of venire contra factum proprium.

> Also what about the termination clause? According to [0] §4 says something 
> along the lines of "Under v2, violators forfeit their rights to redistribute 
> and modify the GPL’d software until those rights are explicitly reinstated by 
> the copyright holder."
> 
> So while they may not be sued, they probably still also don't get the 
> redistribution and modification rights?
> 
> 
> [0] https://softwarefreedom.org/resources/2008/compliance-guide.html

Estoppel means all clauses that the licensor would violate are rendered
undenforceable if the licensee violates them in the same manner.  That
doesn't mean estoppel extinguishes the termination clause but it does
mean you cannot use the termination clause to give alternative effect to
the estopped license breach.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Thu, 2015-07-30 at 06:48 -0700, James Bottomley wrote:
> 
> OK, let us suppose for the sake of argument that this is correct and the
> GPL does manage to get extended to non derived included projects.

Let's not say "non derived included projects". Let's say "independent
and separate works". Since that's the wording the GPL uses when it lays
out the circumstances under which it extends "to the entire whole, and
thus to each and every part regardless of who wrote it".

I know, we disagree on precisely *what* those circumstances are, But
there have to be *some* circumstances, otherwise that whole paragraph
or three of the GPL are just self-contradictory nonsense, right? Which
is surely not a reasonable interpretation of its meaning.

> Even in that case, we're not causing any corporate legal jeopardy 
> because of the principle of estoppel.  Estoppel says we cannot accuse 
> someone of breaching our licence for something we also did. 

Well, Linus deliberately hasn't obtained copyright assignments, so
blithely talking about "we" in that sense is making certain assumptions
and opening up an interesting can of worms. But if you consider it a
joint work it makes some sense to argue that way.

The thing is, it could be argued that in that case "we" don't need a
licence for using "our" own code. So we wouldn't *be* violating the
licence per se, because we don't need one :)

You could reasonably apply estoppel to the case of old kernels where we
*did* actually ship certain firmware as part of the kernel, and someone
is being sued for just building that kernel as-is.

It's much less clear that you could argue that way in court when you
added your *own* firmware to an image, especially of a modern kernel
after we've *removed* the bits we had before. You'd basically be making
the argument "hey, *they* did it in their own code base so they need to
permit *me* to do it... with their code base."

Which is not entirely guaranteed to pass muster. But sure, you can try
it on :)

>  So if we ship the firmware with the kernel, anyone else also 
> shipping firmware with the kernel is automatically innoculated 
> against accusations of license breach for that action.

Although when we pull in GPL'd code from elsewhere which *wasn't*
originally submitted to our 'joint work', that would mean *we* violated
the GPL on that original external code.

If we get our act together and evict the problematic non-GPL parts (as
we did), that puts us back in compliance again... and certainly doesn't
give third parties carte blanche to also violate the licence, just
because *we* made that mistake.

But sure, if a party were very keen to encourage and condone such
behaviour, they could certainly try making the estoppel-based
arguments. They might get lucky.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

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

On Thu, 2015-07-30 at 16:01 +0100, David Woodhouse wrote:
> On Thu, 2015-07-30 at 06:48 -0700, James Bottomley wrote:
> > 
> > OK, let us suppose for the sake of argument that this is correct and the
> > GPL does manage to get extended to non derived included projects.
> 
> Let's not say "non derived included projects". Let's say "independent
> and separate works". Since that's the wording the GPL uses when it lays
> out the circumstances under which it extends "to the entire whole, and
> thus to each and every part regardless of who wrote it".
> 
> I know, we disagree on precisely *what* those circumstances are, But
> there have to be *some* circumstances, otherwise that whole paragraph
> or three of the GPL are just self-contradictory nonsense, right? Which
> is surely not a reasonable interpretation of its meaning.

Well as you know, we disagree.  To me it reads like a confirmation of
the fact that the license won't get into questions of what constitutes
derivation.  It will merely take whatever the jurisdiction says and make
the reach of the license follow that.  It's actually a very clever ploy
because it means the license can never be attacked for having a
provision contrary to copyright law.

> > Even in that case, we're not causing any corporate legal jeopardy 
> > because of the principle of estoppel.  Estoppel says we cannot accuse 
> > someone of breaching our licence for something we also did. 
> 
> Well, Linus deliberately hasn't obtained copyright assignments, so
> blithely talking about "we" in that sense is making certain assumptions
> and opening up an interesting can of worms. But if you consider it a
> joint work it makes some sense to argue that way.
> 
> The thing is, it could be argued that in that case "we" don't need a
> licence for using "our" own code. So we wouldn't *be* violating the
> licence per se, because we don't need one :)

I'm afraid that's sophistry.  You're arguing law.  Estoppel is based on
fact.  The two facts to be decided for this would be

     1. What is the original source for the work
     2. Does that original source commit or contemplate the breach at
        issue.

There's no ambiguity about the answers:

     1. Linus' git tree
     2. yes, because that was the original premise of the question.

What any of the individual authors opinions are (or even what a court
construes the licence to mean) is irrelevant the facts govern the
finding.

> You could reasonably apply estoppel to the case of old kernels where we
> *did* actually ship certain firmware as part of the kernel, and someone
> is being sued for just building that kernel as-is.

The question of how long after the breach at issue is cured in the
original source does the action remain estopped is a law one which I
won't answer.  The original question wasn't about that, it was whether
shipping firmware as part of the kernel source tree would cause
potential legal jeopardy for onward distributors.  The answer is no, as
you agree above.

> It's much less clear that you could argue that way in court when you
> added your *own* firmware to an image, especially of a modern kernel
> after we've *removed* the bits we had before. You'd basically be making
> the argument "hey, *they* did it in their own code base so they need to
> permit *me* to do it... with their code base."
> 
> Which is not entirely guaranteed to pass muster. But sure, you can try
> it on :)

The original question wasn't "can anyone ship arbitrary firmware with
the kernel" it was "if the kernel ships firmware would this be a license
violation for an onward distributor".  I can hazard an answer to the new
question, but I won't because it's just expanding the basis for
argument.

James

> >  So if we ship the firmware with the kernel, anyone else also 
> > shipping firmware with the kernel is automatically innoculated 
> > against accusations of license breach for that action.
> 
> Although when we pull in GPL'd code from elsewhere which *wasn't*
> originally submitted to our 'joint work', that would mean *we* violated
> the GPL on that original external code.
> 
> If we get our act together and evict the problematic non-GPL parts (as
> we did), that puts us back in compliance again... and certainly doesn't
> give third parties carte blanche to also violate the licence, just
> because *we* made that mistake.
> 
> But sure, if a party were very keen to encourage and condone such
> behaviour, they could certainly try making the estoppel-based
> arguments. They might get lucky.
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5819 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Tim Bird]

On 07/30/2015 08:01 AM, David Woodhouse wrote:
> On Thu, 2015-07-30 at 06:48 -0700, James Bottomley wrote:
>>
>> OK, let us suppose for the sake of argument that this is correct and the
>> GPL does manage to get extended to non derived included projects.
> 
> Let's not say "non derived included projects". Let's say "independent
> and separate works". Since that's the wording the GPL uses when it lays
> out the circumstances under which it extends "to the entire whole, and
> thus to each and every part regardless of who wrote it".
> 
...
> But sure, if a party were very keen to encourage and condone such
> behaviour, they could certainly try making the estoppel-based
> arguments. They might get lucky.
> 

These sorts of discussions of legal issues in a public and persistent
form sometimes do more harm than good.  I don't think that people
will resolve their differences on the list (or maybe at all).  However, 
I do think that noting the differences is sufficient for us to decide if
further face-fo-face discussion is warranted. Can I recommend that we
follow up with discussion at the summit, if people are so inclined?
 -- Tim

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Thu, 2015-07-30 at 09:17 -0700, James Bottomley wrote:
> Well as you know, we disagree.  To me it reads like 

Thank you. I'm happy enough seeing "to me it reads like", followed by
something I disagree with, rather than a claim of absolute truth.
Especially in a case where we're hypothesising about what a court
*might* rule, and we all know that courts can do entirely insane
things.

That was the reason I jumped in.

I'm still kind of interested in what you think it means in the
paragraph which explicitly refers to identifiable sections of a work
which are "not derived from the Program, and can be reasonably
considered independent and separate works in themselves", and concludes
with the words "to each and every part regardless of who wrote it". 

As I understand your viewpoint so far, you seem to have rendered that
whole paragraph entirely meaningless. But having got to this point I'm
not sure I'm interested *enough* to continue that part of the
conversation :)

> The original question wasn't about that, it was
> whether shipping firmware as part of the kernel source tree would 
> cause potential legal jeopardy for onward distributors.  The answer 
> is no, as you agree above.

In the circumstance where the kernel is considered a joint work and its
authors are considered to have consented to that inclusion, sure.

But estoppel doesn't help if we've pulled in GPL'd code from third
parties (which we have), and if *those* third parties object to the
combination of their code in a way that (as you said we could suppose
for the sake of argument) violates the GPL. Which they might.

In that case, *we* have violated the licence of the third party code
that we pulled in. That doesn't give onward distributors a free pass.

But Tim is right; this discussion is probably not really beneficial.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Theodore Ts'o]

I will note that this thread is a great demonstration why I very
*firmly* believe that legal issues (whether it is about license
interpretation or enforcement) should be completely out of scope for
the kernel summit.

About the only thing worse than programmers thinking they can play
lawyers on TV and render legal opinions are physicists at national
labs thinking they can tell computer science people how to design
operating systems and design scale-out computing architectures because
everything can be derived from F=ma.  :-)

						- Ted

On Thu, Jul 30, 2015 at 08:17:00PM +0100, David Woodhouse wrote:
> On Thu, 2015-07-30 at 09:17 -0700, James Bottomley wrote:
> > Well as you know, we disagree.  To me it reads like 
> 
> Thank you. I'm happy enough seeing "to me it reads like", followed by
> something I disagree with, rather than a claim of absolute truth.
> Especially in a case where we're hypothesising about what a court
> *might* rule, and we all know that courts can do entirely insane
> things.
> 
> That was the reason I jumped in.
> 
> I'm still kind of interested in what you think it means in the
> paragraph which explicitly refers to identifiable sections of a work
> which are "not derived from the Program, and can be reasonably
> considered independent and separate works in themselves", and concludes
> with the words "to each and every part regardless of who wrote it". 
> 
> As I understand your viewpoint so far, you seem to have rendered that
> whole paragraph entirely meaningless. But having got to this point I'm
> not sure I'm interested *enough* to continue that part of the
> conversation :)
> 
> > The original question wasn't about that, it was
> > whether shipping firmware as part of the kernel source tree would 
> > cause potential legal jeopardy for onward distributors.  The answer 
> > is no, as you agree above.
> 
> In the circumstance where the kernel is considered a joint work and its
> authors are considered to have consented to that inclusion, sure.
> 
> But estoppel doesn't help if we've pulled in GPL'd code from third
> parties (which we have), and if *those* third parties object to the
> combination of their code in a way that (as you said we could suppose
> for the sake of argument) violates the GPL. Which they might.
> 
> In that case, *we* have violated the licence of the third party code
> that we pulled in. That doesn't give onward distributors a free pass.
> 
> But Tim is right; this discussion is probably not really beneficial.
> 
> -- 
> dwmw2



> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Tim Bird]

On 07/31/2015 07:41 AM, Theodore Ts'o wrote:
> I will note that this thread is a great demonstration why I very
> *firmly* believe that legal issues (whether it is about license
> interpretation or enforcement) should be completely out of scope for
> the kernel summit.
> 
> About the only thing worse than programmers thinking they can play
> lawyers on TV and render legal opinions are physicists at national
> labs thinking they can tell computer science people how to design
> operating systems and design scale-out computing architectures because
> everything can be derived from F=ma.

I agree with the sentiment.  But I do think kernel developers can have
some role in expressing the will and intention of the copyright holders
(to the degree that's possible on a massively distributed project
like the kernel).  As a hypothetical, if we wanted to create a safe
haven for people to distribute binary firmware blobs linked to the
kernel, it might be legally worthwhile to create and publish a statement
from major stakeholders (who are themselves copyright holders as well
as technical experts) on the issue.  Lawyers use statements from technical
experts fairly often.

I can't think of a better place than a kernel summit (well, maybe
inside the TAB) where kernel developers could use face-to-face
communication to determine if there's consensus on this, as a
first step in creating such a statement.

I have no idea if this issue rises to the level of concern that would
warrant such action.  My own experience is that most companies with
binary firmware blobs have by now figured out how to distribute them
in a way that they believe satisfies the requirements of the GPL.
 -- Tim

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Fri, 2015-07-31 at 09:14 -0700, Tim Bird wrote:
> On 07/31/2015 07:41 AM, Theodore Ts'o wrote:
> > I will note that this thread is a great demonstration why I very
> > *firmly* believe that legal issues (whether it is about license
> > interpretation or enforcement) should be completely out of scope 
> > for the kernel summit.

To a certain extent, I agree. You'll note my argument with James and
Greg was basically saying "you cannot make blanket statements like
that", rather than arguing that any particular interpretation was
"correct".

But there *is* a merit in a having a report from those who are actually
involved in compliance and enforcement "on the ground". Even if some
details of specific ongoing cases cannot be fully disclosed, there is a
lot of FUD and politicking around even what these entities are doing in
the *general* case and how they approach matters. It would be good to
have a proper discussion of the *facts* around that.

Even setting aside the question of "absolute truth", it is interesting
to note James's and Greg's opinions. I think a number of individual
contributors may also be very interested to hear a clear statement of
the LF's position on such matters — again in terms of the advice they
actually give in real cases, rather than pontification and speculation.

A number of people do currently seem to be a little concerned that the
LF might *not* be entirely representing their desires and their best
interests, so it would be good to have some clarity there.

> I agree with the sentiment.  But I do think kernel developers can 
> have some role in expressing the will and intention of the copyright
> holders

Agreed.

> (to the degree that's possible on a massively distributed project
> like the kernel).  As a hypothetical, if we wanted to create a safe
> haven for people to distribute binary firmware blobs linked to the
> kernel,

To be honest, we don't. There are basically *no* technical reasons to
need firmware linked directly into the kernel. Hell, you can even put
it into an initramfs and do NFS root without needing to do that kind of
thing. We actually agreed at the Kernel Summit in Boston that we could
rip out the legacy images that were being distributed with the kernel
source.

One of the reasons I haven't done that yet — not that I always need a
reason for failing to get round to something — is because it just gets
easier as time goes on. We have an old and incomplete and largely out
of date set of legacy firmware in the firmware/ directory and these
days I think *everyone* is using the separate linux-firmware stuff, so
it should actually be a no-brainer now. Which means I should probably
get on with it at last.

>  it might be legally worthwhile to create and publish a statement 
> from major stakeholders (who are themselves copyright holders as well 
> as technical experts) on the issue.  Lawyers use statements from
> technical experts fairly often.

The interesting one there is not so much firmware as binary modules in
an embedded work. A wireless router is a prime example — where if
*either* the kernel or the binary wifi driver were missing, the work
would have no value. That's one of the poster children for being a
coherent combined work rather than merely aggregation (again, I'm not
claiming truth; only saying that there are those who will argue it).

> I can't think of a better place than a kernel summit (well, maybe
> inside the TAB) where kernel developers could use face-to-face
> communication to determine if there's consensus on this, as a
> first step in creating such a statement.

I don't think we'll ever truly gain consensus. There are those who
choose to interpret it in a permissive way, like James, and there are
others who choose to interpret it in a less permissive way. And have
gone on record as stating that they *are* going to sue a distributor of
combined kernel+module works at some point in the near future.

But even without enough of a consensus to make a coherent statement, it
would still be useful to have an idea of where the distributions of
opinions lies.

And it's also useful to talk about what people *want* it to mean.
You've seen from James's and my discussion that we can decide what we
*want* and then choose to interpret the language to support our
desires.

Are most people happy with binary modules existing at all? Would people
prefer just to switch to a BSD licence for the kernel and stop all the
whining? Are people happy with the embedded products using binary
modules and being *useless* without them? These are all interesting
questions almost regardless of whether we can choose to interpret the
GPL to support our desires. :)

It would be interesting to have a show of hands on those things —
asking both "do you *want* the licence to..." and "do you *believe* the
licence..." in both cases.

> I have no idea if this issue rises to the level of concern that would
> warrant such action.

For firmware, no. But there is a *lot* of FUD around the whole GPL
enforcement issue, even between those who are on *our* side. At times
it seems like we could summon all who purport themselves to be the
"good guys" working on behalf of the people at the Kernel Summit, and
bash their heads together like naughty children.

I'm not actually proposing that we bash heads, but I would like to get
people to sit down in the room and have an adult and factual
discussion.

But yes, absolutely *not* for pontificating and speculation about what
a court would do.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Hi James,

The top patch here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2

allows demand loading of keys based on their SKID into a special keyring from
which they get erased after an arbitrary 3 minutes of existence.  This key can
then be used to verify a signature instead of using the primary system keyring
used for module signature checking.

Building on this, a driver could have a SKID compiled into it which could then
be used to load a key for request_firmware() to use in verifying the blobs
that that driver requires.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Tue, Aug 11, 2015 at 1:24 PM, David Howells <dhowells@redhat.com> wrote:
> Hi James,
>
> The top patch here:
>
>         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2
>
> allows demand loading of keys based on their SKID into a special keyring from
> which they get erased after an arbitrary 3 minutes of existence.  This key can
> then be used to verify a signature instead of using the primary system keyring
> used for module signature checking.
>
> Building on this, a driver could have a SKID compiled into it which could then
> be used to load a key for request_firmware() to use in verifying the blobs
> that that driver requires.
>

Who signs the vendor key?

Why are we bothering loading device vendor keys into a keyring in the
first place?  Why not just have an API to request firmware either
signed by a literal key provided by the driver *or* whatever keys the
system trusts in general for firmware signing?

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Luis R. Rodriguez]

On Tue, Aug 11, 2015 at 2:56 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>  Why not just have an API to request firmware either
> signed by a literal key provided by the driver *or* whatever keys the
> system trusts in general for firmware signing?

The new sysdata API I posted would in turn enable such things for the
firmware API, regardless of what is decided for the other things you
asked.

 Luis

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Andy Lutomirski <luto@amacapital.net> wrote:

> > The top patch here:
> >
> >         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2
> >
> > allows demand loading of keys based on their SKID into a special keyring from
> > which they get erased after an arbitrary 3 minutes of existence.  This key can
> > then be used to verify a signature instead of using the primary system keyring
> > used for module signature checking.
> >
> > Building on this, a driver could have a SKID compiled into it which could then
> > be used to load a key for request_firmware() to use in verifying the blobs
> > that that driver requires.
> >
> 
> Who signs the vendor key?

From the arguments so far presented, the vendor - but possibly allowing the
linux-fimrware manager to sign in lieu if the admin of a machine running this
stuff allows it.

> Why are we bothering loading device vendor keys into a keyring in the
> first place?

Caching.  Some drivers need more than one firmware blob.

> Why not just have an API to request firmware either signed by a literal key
> provided by the driver *or* whatever keys the system trusts in general for
> firmware signing?

By "a literal key provided by the driver" I presume you mean that the parts of
the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
could do this quite easily - key_create_or_update() will turn a binary key
blob into a struct key * that can then be used.  Do we want ~1.5K or more of
undiscardable data per key adding to each module that wants to load firmware,
particularly if it needs to carry several keys just in case one gets revoked?

Objections have been raised against using general keys for firmware signing.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Woodhouse]

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

On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
> By "a literal key provided by the driver" I presume you mean that the parts of
> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
> could do this quite easily - key_create_or_update() will turn a binary key
> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
> undiscardable data per key adding to each module that wants to load firmware,
> particularly if it needs to carry several keys just in case one gets revoked?

No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
SKID is *usually* a hash of the public key, but isn't guaranteed to be
so, so using the SKID to specify the acceptable signing cert isn't
secure.

The actual signing cert doesn't need to be present in full because we
can require it to be present in the PKCS#7 signature.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

¹ Or indeed a hash of the only acceptable firmware image(s), if that's  appropriate for some use cases.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 11:22 AM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> > The top patch here:
>> >
>> >         http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7-2
>> >
>> > allows demand loading of keys based on their SKID into a special keyring from
>> > which they get erased after an arbitrary 3 minutes of existence.  This key can
>> > then be used to verify a signature instead of using the primary system keyring
>> > used for module signature checking.
>> >
>> > Building on this, a driver could have a SKID compiled into it which could then
>> > be used to load a key for request_firmware() to use in verifying the blobs
>> > that that driver requires.
>> >
>>
>> Who signs the vendor key?
>
> From the arguments so far presented, the vendor - but possibly allowing the
> linux-fimrware manager to sign in lieu if the admin of a machine running this
> stuff allows it.

The device vendor?

How do you plan on requesting a self-signed vendor key with any kind
of security if there isn't some root of trust in the kernel.

>
>> Why are we bothering loading device vendor keys into a keyring in the
>> first place?
>
> Caching.  Some drivers need more than one firmware blob.
>
>> Why not just have an API to request firmware either signed by a literal key
>> provided by the driver *or* whatever keys the system trusts in general for
>> firmware signing?
>
> By "a literal key provided by the driver" I presume you mean that the parts of
> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
> could do this quite easily - key_create_or_update() will turn a binary key
> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
> undiscardable data per key adding to each module that wants to load firmware,
> particularly if it needs to carry several keys just in case one gets revoked?

1.5K?  I'm talking about an actual raw public key, which is 65 bytes
or less in reasonable implementations.  (64 or 65 bytes for P-256
depending on encoding and 32 bytes for compressed schemes like EdDSA.)

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 11:45 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
>> By "a literal key provided by the driver" I presume you mean that the parts of
>> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
>> could do this quite easily - key_create_or_update() will turn a binary key
>> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
>> undiscardable data per key adding to each module that wants to load firmware,
>> particularly if it needs to carry several keys just in case one gets revoked?
>
> No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
> SKID is *usually* a hash of the public key, but isn't guaranteed to be
> so, so using the SKID to specify the acceptable signing cert isn't
> secure.
>
> The actual signing cert doesn't need to be present in full because we
> can require it to be present in the PKCS#7 signature.

Screw the cert.  It doesn't certify anything -- it's just a bloated
wrapper around a public key.  It's not even worth the space in /lib it
takes up.

Once we're talking real, modern public keys, there's no point in even
hashing them.  A good cryptosystem will have 32-byte public keys, and
a sufficiently strong hash will be 32 bytes.  Maybe hashing makes a
little bit of sense if we're stuck with RSA for some reason.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Wed, 2015-08-12 at 12:09 -0700, Andy Lutomirski wrote:
> On Wed, Aug 12, 2015 at 11:45 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
> >> By "a literal key provided by the driver" I presume you mean that the parts of
> >> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
> >> could do this quite easily - key_create_or_update() will turn a binary key
> >> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
> >> undiscardable data per key adding to each module that wants to load firmware,
> >> particularly if it needs to carry several keys just in case one gets revoked?
> >
> > No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
> > SKID is *usually* a hash of the public key, but isn't guaranteed to be
> > so, so using the SKID to specify the acceptable signing cert isn't
> > secure.
> >
> > The actual signing cert doesn't need to be present in full because we
> > can require it to be present in the PKCS#7 signature.
> 
> Screw the cert.  It doesn't certify anything -- it's just a bloated
> wrapper around a public key.  It's not even worth the space in /lib it
> takes up.

I don't think we can entirely do that.  I agree the kernel only needs to
know that the owner of the firmware root of trust is happy with the
public key to verify the firmware signature.  However, the owner of the
firmware root of trust might like to satisfy themselves that the key was
genuinely issued by the people who should be providing the firmware.  To
do that, they need to check the certificate chain.  I agree this can be
done in userspace and doesn't have to be done by the kernel.

> Once we're talking real, modern public keys, there's no point in even
> hashing them.  A good cryptosystem will have 32-byte public keys, and
> a sufficiently strong hash will be 32 bytes.  Maybe hashing makes a
> little bit of sense if we're stuck with RSA for some reason.

I'm slightly confused by this comment: If you're thinking of Elliptic
Curve Cryptography, then it is simply RSA, just done over a more funky
mathematical structure that yields shorter keys.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 12:15 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2015-08-12 at 12:09 -0700, Andy Lutomirski wrote:
>> On Wed, Aug 12, 2015 at 11:45 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
>> >> By "a literal key provided by the driver" I presume you mean that the parts of
>> >> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
>> >> could do this quite easily - key_create_or_update() will turn a binary key
>> >> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
>> >> undiscardable data per key adding to each module that wants to load firmware,
>> >> particularly if it needs to carry several keys just in case one gets revoked?
>> >
>> > No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
>> > SKID is *usually* a hash of the public key, but isn't guaranteed to be
>> > so, so using the SKID to specify the acceptable signing cert isn't
>> > secure.
>> >
>> > The actual signing cert doesn't need to be present in full because we
>> > can require it to be present in the PKCS#7 signature.
>>
>> Screw the cert.  It doesn't certify anything -- it's just a bloated
>> wrapper around a public key.  It's not even worth the space in /lib it
>> takes up.
>
> I don't think we can entirely do that.  I agree the kernel only needs to
> know that the owner of the firmware root of trust is happy with the
> public key to verify the firmware signature.  However, the owner of the
> firmware root of trust might like to satisfy themselves that the key was
> genuinely issued by the people who should be providing the firmware.  To
> do that, they need to check the certificate chain.  I agree this can be
> done in userspace and doesn't have to be done by the kernel.

I don't think it belongs in deployed userspace either.  This should be
the distro's job, and we shouldn't have to care how the distro does
it.  We have no business deciding whether $VENDOR's alleged public key
is valid at runtime.

>
>> Once we're talking real, modern public keys, there's no point in even
>> hashing them.  A good cryptosystem will have 32-byte public keys, and
>> a sufficiently strong hash will be 32 bytes.  Maybe hashing makes a
>> little bit of sense if we're stuck with RSA for some reason.
>
> I'm slightly confused by this comment: If you're thinking of Elliptic
> Curve Cryptography, then it is simply RSA, just done over a more funky
> mathematical structure that yields shorter keys.

Not quite.  ECC signatures are generally Schnorr-based (except ECDSA,
which is kind of like a bastardized Schnorr signature that avoids the
now-expired patent AUIU), but they're not based on exponentiation at
all.

RSA signatures are (loosely) based on the idea that only the private
key holder knows the period of exponentiation in the key pair's group.
In ECC schemes, the group is generally a globally constant parameter,
and the private key's holder doesn't know anything special about the
group, so you need a different approach entirely.

All that's moot, though.  IMO the only reason we should support RSA
here is if there are vendor keys already out there (or Authenticode,
sigh) that use RSA.  RSA keys and signatures are rather large.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
> On Wed, Aug 12, 2015 at 12:15 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2015-08-12 at 12:09 -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 12, 2015 at 11:45 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> > On Wed, 2015-08-12 at 19:22 +0100, David Howells wrote:
> >> >> By "a literal key provided by the driver" I presume you mean that the parts of
> >> >> the key (perhaps an X.509 cert) are actually compiled into the driver.  Yes we
> >> >> could do this quite easily - key_create_or_update() will turn a binary key
> >> >> blob into a struct key * that can then be used.  Do we want ~1.5K or more of
> >> >> undiscardable data per key adding to each module that wants to load firmware,
> >> >> particularly if it needs to carry several keys just in case one gets revoked?
> >> >
> >> > No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
> >> > SKID is *usually* a hash of the public key, but isn't guaranteed to be
> >> > so, so using the SKID to specify the acceptable signing cert isn't
> >> > secure.
> >> >
> >> > The actual signing cert doesn't need to be present in full because we
> >> > can require it to be present in the PKCS#7 signature.
> >>
> >> Screw the cert.  It doesn't certify anything -- it's just a bloated
> >> wrapper around a public key.  It's not even worth the space in /lib it
> >> takes up.
> >
> > I don't think we can entirely do that.  I agree the kernel only needs to
> > know that the owner of the firmware root of trust is happy with the
> > public key to verify the firmware signature.  However, the owner of the
> > firmware root of trust might like to satisfy themselves that the key was
> > genuinely issued by the people who should be providing the firmware.  To
> > do that, they need to check the certificate chain.  I agree this can be
> > done in userspace and doesn't have to be done by the kernel.
> 
> I don't think it belongs in deployed userspace either.  This should be
> the distro's job, and we shouldn't have to care how the distro does
> it.  We have no business deciding whether $VENDOR's alleged public key
> is valid at runtime.

Users who don't trust (or build their own) distro tend to like to verify
these things themselves.  Even basic security would suggest that you
should check everything you can check yourself just in case the third
party were accidentally compromised.

> >> Once we're talking real, modern public keys, there's no point in even
> >> hashing them.  A good cryptosystem will have 32-byte public keys, and
> >> a sufficiently strong hash will be 32 bytes.  Maybe hashing makes a
> >> little bit of sense if we're stuck with RSA for some reason.
> >
> > I'm slightly confused by this comment: If you're thinking of Elliptic
> > Curve Cryptography, then it is simply RSA, just done over a more funky
> > mathematical structure that yields shorter keys.
> 
> Not quite.  ECC signatures are generally Schnorr-based (except ECDSA,
> which is kind of like a bastardized Schnorr signature that avoids the
> now-expired patent AUIU), but they're not based on exponentiation at
> all.
> 
> RSA signatures are (loosely) based on the idea that only the private
> key holder knows the period of exponentiation in the key pair's group.
> In ECC schemes, the group is generally a globally constant parameter,
> and the private key's holder doesn't know anything special about the
> group, so you need a different approach entirely.
> 
> All that's moot, though.  IMO the only reason we should support RSA
> here is if there are vendor keys already out there (or Authenticode,
> sigh) that use RSA.  RSA keys and signatures are rather large.

In either case security rests on the discrete log problem.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 12:43 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
>> All that's moot, though.  IMO the only reason we should support RSA
>> here is if there are vendor keys already out there (or Authenticode,
>> sigh) that use RSA.  RSA keys and signatures are rather large.
>
> In either case security rests on the discrete log problem.

RSA is based on factoring, not discrete log.

(With a caveat:
http://crypto.stackexchange.com/questions/802/would-the-ability-to-efficiently-find-discrete-logs-have-any-impact-on-the-secur)

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Wed, 2015-08-12 at 12:45 -0700, Andy Lutomirski wrote:
> On Wed, Aug 12, 2015 at 12:43 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
> >> All that's moot, though.  IMO the only reason we should support RSA
> >> here is if there are vendor keys already out there (or Authenticode,
> >> sigh) that use RSA.  RSA keys and signatures are rather large.
> >
> > In either case security rests on the discrete log problem.
> 
> RSA is based on factoring, not discrete log.

Security is based on the discrete log:  RSA relates the private to the
public key via an inverse operation:  if you can solve the discrete log
problem, you can recover the private key from just the public key.  If
you can factor n in RSA, you can also recover the public key.  It is a
theorem that these two problems are effectively equivalent.

James

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Andy Lutomirski <luto@amacapital.net> wrote:

> 1.5K?  I'm talking about an actual raw public key, which is 65 bytes
> or less in reasonable implementations.  (64 or 65 bytes for P-256
> depending on encoding and 32 bytes for compressed schemes like EdDSA.)

Various bodies that define security criteria with which one must comply to be
able to supply software mandate key lengths of at least 2048 bits - that is
min 256 bytes.

But yes, we could even take a raw public key and just fill in a public_key
structure for it and then use it.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

David Woodhouse <dwmw2@infradead.org> wrote:

> No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
> SKID is *usually* a hash of the public key, but isn't guaranteed to be
> so, so using the SKID to specify the acceptable signing cert isn't
> secure.

True.  That's one of the reasons I don't like SKIDs - the specification is
very vague and non-enforcing.  We would need a 'standard' for how to hash the
public key data.  Some types of public key, for example, have more than one
integer.  I wonder if we could just take the PGP method as the standard -
though that does require extra elements.

> The actual signing cert doesn't need to be present in full because we
> can require it to be present in the PKCS#7 signature.

True.  I suppose for firmware this might not be so bad since any particular
public key isn't going to sign all that many blobs, so having duplicates
wouldn't take up all that much space.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 3:39 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> 1.5K?  I'm talking about an actual raw public key, which is 65 bytes
>> or less in reasonable implementations.  (64 or 65 bytes for P-256
>> depending on encoding and 32 bytes for compressed schemes like EdDSA.)
>
> Various bodies that define security criteria with which one must comply to be
> able to supply software mandate key lengths of at least 2048 bits - that is
> min 256 bytes.
>

Really?  Doesn't even FIPS prefer ECDSA on P-256 these days?  Your
employer has decided that the patent situation is acceptable. :)

Any standards body that says "minimum key length of 2048 bits" as
opposed to "minimum RSA or DSA key length of 2048 bits" with separate
criteria for EC groups is just nuts.

> But yes, we could even take a raw public key and just fill in a public_key
> structure for it and then use it.

I prefer that over certificates.  Smaller and simpler.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[David Howells]

Andy Lutomirski <luto@amacapital.net> wrote:

> Once we're talking real, modern public keys, there's no point in even
> hashing them.  A good cryptosystem will have 32-byte public keys, and
> a sufficiently strong hash will be 32 bytes.

And likely non-compliant with various security certifications.

David

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 3:45 PM, David Howells <dhowells@redhat.com> wrote:
> David Woodhouse <dwmw2@infradead.org> wrote:
>
>> No. Just use a *hash* of the acceptable signing cert(s)¹. Note that the
>> SKID is *usually* a hash of the public key, but isn't guaranteed to be
>> so, so using the SKID to specify the acceptable signing cert isn't
>> secure.
>
> True.  That's one of the reasons I don't like SKIDs - the specification is
> very vague and non-enforcing.  We would need a 'standard' for how to hash the
> public key data.  Some types of public key, for example, have more than one
> integer.  I wonder if we could just take the PGP method as the standard -
> though that does require extra elements.

This is a major benefit of modern (or modernish) ECC schemes: the
public key is pretty much unambiguously represented as a byte string.

(IIRC P-256 has some variable length garbage for part of it, but we
could pick any of the common representations and stick with it.  I
think that pretty much everyone agrees on something along the line of
0x04 plus the big-endian representation of the point in some standard
coordinate system, for 65 unambiguous bytes.)

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Andy Lutomirski]

On Wed, Aug 12, 2015 at 3:46 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>
>> Once we're talking real, modern public keys, there's no point in even
>> hashing them.  A good cryptosystem will have 32-byte public keys, and
>> a sufficiently strong hash will be 32 bytes.
>
> And likely non-compliant with various security certifications.

Humor me: what security certification would not be okay with 65 bytes
of ECDSA/P-256 public key?  And what security certification would not
be okay with the SHA-256 (or SHA3-256) hash of something appropriate?

Even with compression, the standards should accept any representation
whatsoever that is *decompressed* to the correct 65-byte octet string
prior to calling into any crypto code.  Of course, there are (or were
or something) those who claim to have or have had patents on that,
from my extremely vague memory.

--Andy

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[Jan Kara]

On Wed 12-08-15 12:59:51, James Bottomley wrote:
> On Wed, 2015-08-12 at 12:45 -0700, Andy Lutomirski wrote:
> > On Wed, Aug 12, 2015 at 12:43 PM, James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
> > >> All that's moot, though.  IMO the only reason we should support RSA
> > >> here is if there are vendor keys already out there (or Authenticode,
> > >> sigh) that use RSA.  RSA keys and signatures are rather large.
> > >
> > > In either case security rests on the discrete log problem.
> > 
> > RSA is based on factoring, not discrete log.
> 
> Security is based on the discrete log:  RSA relates the private to the
> public key via an inverse operation:  if you can solve the discrete log
> problem, you can recover the private key from just the public key.  If
> you can factor n in RSA, you can also recover the public key.  It is a
> theorem that these two problems are effectively equivalent.

As the reference Andy gave explains, it depends on the exact definition of
the "discrete log problem". Discrete log operation can be defined for
arbitrary group. Knowing how to solve discrete log problem for some groups
(e.g. for Z_p where p is a prime) doesn't easily give you a way to infer
private RSA key from a public one. If you can solve discrete log for
Z_{p*q}, then yes, you can break RSA as well.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [Ksummit-discuss] [TECH TOPIC] Firmware signing

[James Bottomley]

On Thu, 2015-08-13 at 09:03 +0200, Jan Kara wrote:
> On Wed 12-08-15 12:59:51, James Bottomley wrote:
> > On Wed, 2015-08-12 at 12:45 -0700, Andy Lutomirski wrote:
> > > On Wed, Aug 12, 2015 at 12:43 PM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > On Wed, 2015-08-12 at 12:25 -0700, Andy Lutomirski wrote:
> > > >> All that's moot, though.  IMO the only reason we should support RSA
> > > >> here is if there are vendor keys already out there (or Authenticode,
> > > >> sigh) that use RSA.  RSA keys and signatures are rather large.
> > > >
> > > > In either case security rests on the discrete log problem.
> > > 
> > > RSA is based on factoring, not discrete log.
> > 
> > Security is based on the discrete log:  RSA relates the private to the
> > public key via an inverse operation:  if you can solve the discrete log
> > problem, you can recover the private key from just the public key.  If
> > you can factor n in RSA, you can also recover the public key.  It is a
> > theorem that these two problems are effectively equivalent.
> 
> As the reference Andy gave explains, it depends on the exact definition of
> the "discrete log problem". Discrete log operation can be defined for
> arbitrary group. Knowing how to solve discrete log problem for some groups
> (e.g. for Z_p where p is a prime) doesn't easily give you a way to infer
> private RSA key from a public one. If you can solve discrete log for
> Z_{p*q}, then yes, you can break RSA as well.

The conjecture is that the discrete log problem is solved for a prime
ring. (Solved means algorithmically feasible with current computers and
ring sizes).  The ring used for RSA, as you point out is p*q, which is
actually a composite Z_p \otimes Z_q  (RSA chooses p and q to be
similarly sized).  All the currently known algorithms are exponential
(or worse) in the ring order (well, except Shor's algorithm which
depends on the invention of a quantum computer; Shor's algorithm, by the
way, is polynomial in log order, so the size of the ring becomes a lot
less material, which is why the invention of a quantum computer signals
a disaster in all our current security systems).

It's possible there's an undiscovered classical algorithm that only
works for primes with certain characteristics, but that's speculation.

James