On Tue, Sep 10, 2013 at 11:51 AM, gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Sep 10, 2013 at 11:29:45AM -0700, H. Peter Anvin wrote: >> On 09/10/2013 11:26 AM, Matthew Garrett wrote: >> > On Tue, 2013-09-10 at 14:23 -0300, Henrique de Moraes Holschuh wrote: >> >> On Tue, 10 Sep 2013, Matthew Garrett wrote: >> >>> That's why modern systems require signed firmware updates. >> >> >> >> Linux doesn't. Is someone working on adding signature support to the >> >> runtime firmware loader? >> > >> > It'd be simple to do so, but so far the model appears to be that devices >> > that expect signed firmware enforce that themselves. >> > >> >> Most devices do absolutely no verification on the firmware, and simply >> trust the driver. >> >> So signing firmware is probably critical. > > How are you going to "validate" that the firmware is correct, given > that it's just a "blob" living in the linux-firmware tree. If you sign > it, what is that saying? In theory these blobs are traceable to a manufacturer. It's not really an indication that it's "safe" more than it's an indication that it hasn't been changed. But I haven't chased this very hard yet because of below... > I'm with Matthew here, any device that needs/wants this, has their own > built-in checking, nothing the kernel should do here. > > Especially given that no other os does this :) Yeah, it's impossible to handle since the way components do firmware updates is frequently exposed to userspace anyway. 3G modems that do firmware updates over the AT-command set, harddrives doing firmware updates over SCSI-generic commands, etc. Creating this barrier in the kernel is not a good solution; the component makers need to be doing the enforcement. :( -Kees -- Kees Cook Chrome OS Security -- 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
