On Tue, Dec 05, 2017 at 11:27:58AM +0100, Pavel Machek wrote: > Hi! > > > > Our ability to determine that userland hasn't been tampered with > > > depends on the kernel being trustworthy. If userland can upload > > > arbitrary firmware to DMA-capable devices then we can no longer trust > > > the kernel. So yes, firmware is special. > > > > You're ignoring the whole "firmware is already signed by the hardware > > manufacturer and we don't even have access to it" part. > > Well... I guess we'd prefer the firmware _not_ be signed, so we can > fix security holes in that after the vendor lost interest... Bugs in > the wifi stacks seemed patcheable that way. > > There is GPLed firmware available for some USB wifi's. We really > should make sure firmware signing is not mandatory/encouraged for the hw vendors. I share this concern and interest, specially as more device drivers get purposely stupid and most of the technology and fun things shift to firmware. Its precisely for this same reason why most manufacturers won't be opening up more firmware, as they could argue tons of value-add is in firmware now. One has to be realistic though, as one of the few folks who pushed to open source (and GPL) a few of the open source firmwares we have for WiFi, I realize we have no option but to accept the fate that most manufacturers *will* use and require signed firmware in the future. If you're concerned about this you have only a few options. One is to get more and more folks reverse engineer firmware. This won't help if you can't deploy unsigned firmware though. But you have to also look at it from a practical point of view, in order to do development you *have* to have some sort of knobs to turn off fw signing verification, so it should be a matter of looking hard. And for devices where this is not obvious or almost impossible, hope for an exploit. Another option is to argue for the engineering gain for having open firmware, and a viable sensible and responsible option to continue to do R&D and innovation with open firmware. We did this with WiFi long ago, see CFG80211_CERTIFICATION_ONUS and the slew of open firmware released. The fact that we have open firmware repositories and also a respective proprietary firmwares for the same device could be used to metrically show the gains that such development had over time, in a quantifiable form (features, bug fixes, security issues fixed). There's tons of data available which could enable a researcher to have a field with this. And the last option is to just argue for a sensible opt-out knob to be documented as part of our rights or due to general long term community security interests. Just as with UEFI one can say one does not trust any key present already on the platform, one should also be able to do the same for peripheral devices and their own corresponding firmware -- a knob to disable firmware signing. Sadly *all* of these are lofty pie in the sky objectives. What the likely outcome will be is we sit and wait for the worst of the possible security shit issues to hit the fan for the large IoT universe, and then hope we can use this as leverage to require documenting such opt-out knobs just as with UEFI's opt-out mechanism. Although one would expect that such exploits already have happened, in practice not at the interface we're talking about here, which is for /lib/firmware/. For instance the Intel Management Engine does not use this interface, and neither do some of the storage driver and arrays I've been bluntly told have had tons of backdoors for years. Its precisely because of this lack of known issues with security for /lib/firmware exploits that I'm willing to put signing of /lib/firmware on the side for now. We just haven't had many known attacks come in through here. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
