Re: [RFD] linux-firmware key arrangement for firmware signing

[Luis R. Rodriguez]

On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> > On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > > Signatures don't provide any guarantees as to code quality or
> > > correctness.   They do provide file integrity and provenance.  In
> > > addition to the license and a Signed-off-by line, having the 
> > > firmware provider include a signature of the firmware would be 
> > > nice.
> > 
> > That would be "nice", but that's not going to be happening here, from
> > what I can tell.  The firmware provider should be putting the signature
> > inside the firmware image itself, and verifying it on the device, in
> > order to properly "know" that it should be running that firmware.  The
> > kernel shouldn't be involved here at all, as Alan pointed out.
> 
> In a lot of cases we have loadable firmware precisely to allow us to
> reduce the cost of the hardware. Adding cryptographic capability in the
> 'load firmware' state of the device isn't really compatible with that
> :)

Standards aside -- using crypto functionality on hardware or software are best
practices quite a few folks are picking up. Now, let me remind us that it was
crypto practices in software which in the end allowed us to gain huge corporate
support on the uphill battle to find vendors to start becoming friendly on
working with us upstream on the 802.11 front on Linux.  To be crystal clear,
although providing signature check support for file integrity and provenance
checks might seem like a "dog and pony show" [0] it nevertheless helped us
hugely upstream. For those that wish to side on the "dog and pony show" side
of the argument you have the freedom to do that, and should always have that.
In the end, that flexibility and maintaining peoples freedom's completely
(see CFG80211_CERTIFICATION_ONUS) are IMHO the best form of compromises we
can make for both camps.

There's two sides to the topic at hand:

1) Technical merit
2) Political merit

We went down the road of using some aspects of 1) to win on 2), I can say with
confidence that this was the case for 802.11 to the extend we even now have today
GPLv2 open firmware on linux-firmware. That was a huge win considering we lacked
most vendor support in the beginning. Not sure if something similar is applicable
to modules, there must've been some good amount of 2) and 1) to get it upstream
into Linux after all, I frankly don't care, but I suspect there must be some of it.

Since I can only speak on behalf of one side of the historical aspects of this
from a practical point of view I think we should look at this problem as ensuring
we do what we need to allow us developers to get the job done while folks working
on the political front figure what the fuck is needed from 1) to win 2) -- so long
as they keep our freedoms in mind. Although a few folks trimmed my original
comments about original motivation for this signature checking effort its important
to remind folks on the thread that the original motivation for all this was to
simply come together on a unified solution for both *modules* and 802.11 regulatory
for 2) and 1). On the 802.11 front CRDA has historically been very useful, but
since the kernel got module signature check support we can simply do away with
our own subsystem specific practices and file redistribution mechanism by unifying
our efforts on firmware with file integrity / provenance.

So the quest here is not to shove down folk's distribution's practices or beliefs
but rather simplify things for 802.11 and upkeeping the same flexibility to let
folks enable / disable things. So please keep in mind if you argue over signed
firmware as a solution to replace CRDA upstream, I'd like to also hear an
alternative to do away with it. I don't think expecting folks to use IMA is a
good option yet, from what I had reviewed so far.

So we have 2) and 1) for modules. We have 2) and 1) for 802.11. The goal here
was to simplify redistribution / code by sharing while keeping everyone's
freedoms to ignore all this as well.

Since the focus is to use the technical solution on modules, I think folks are
*seriously* confusing the issues on the technical front with the political. This
is bad! Those folks should simply write their alternative solutions and APIs
if we do not have them yet. What makes this problem harder is we now also have
IMA and LSM and even LSM stacking come to our future Linux tree, this allows
even more flexibility, and IMHO gets folks barking up the wrong trees [1].

What makes thing even more difficult is folks are arguing we now revisit
the technical aspects for modules using IMA while we have other folks
extending the old module technical solution. I think we can have a reasonable
compromise on all fronts here, but this requires a bit more review. Without
completing this review -- I'll prematurely say then that it would seem we could
keep everyone happy by enabling the existing extensions to module signing
to use PKCS#7 while folks who disagree with this figure out what path to
make the decision of what technical solution to use here configurable. Without
a final review on my part I'm inclined to believe we can accomplish this easily
with LSM stacking, by having module signature checks be:

a) optional
b) an LSM module can provide its own file integrity checks
c) the above can provide APIs that can be used for both modules and firmware

We actually already have an LSM hook for modules and firmware so technically
this should already be all possible, and folk who do not want PKCS#7 should
simply disable that stuff. Long term it may make sense to just LSM'ify it.

I believe this would be the right approach because we already went down the
module signing path and folks still working on that due to 1) or 2) are just
extending and perfecting that. Meanwhile, on the 802.11 front we're just trying
to simplify and unify things while keeping folk's beliefs on the dog and pony
show in mind.

> In the case where kernel and modules are signed, it *is* useful for a
> kernel device driver also to be able to validate that what it's about
> to load into a device is authentic. Where 'authentic' will originally
> just mean that it's come from the linux-firmware.git repository or the
> same entity that built (and signed) the kernel, but actually I *do*
> expect vendors who are actively maintaining the firmware images in
> linux-firmware.git to start providing detached signatures of their own.

Although we originally did not discuss this as firmware signature check support
was being fleshed out, I do believe this makes sense and as much dog and pony
show folks want to call this I do believe it will also help us with vendor
support. To this day I can say with a very straight face I believe Linux has
the best regulatory solution on the planet, perhaps this is of little value to
some folks, but I dealt with the politics first hand, I also *know* we have a
great track record to this day on Linux, let's keep it that way and see what
things we can do to make things easier for those technical folks trying to
iron out the politics for us. Now if you want to argue about the political 
aspects of any of this, you can do so, but this is perhaps not the best venue.
We can avoid those issues ourselves by enabling those we trust to create
flexibility to enable the differing leading technical solutions.

[0] https://en.wikipedia.org/wiki/Dog_and_pony_show
[1] https://en.wikipedia.org/wiki/Barking_up_the_wrong_tree

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/