Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Fri, 2017-11-10 at 02:46 +0100, Luis R. Rodriguez wrote:
> On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote:
> > On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote:
> > > But perhaps I'm not understanding the issue well, let me know.
> > 
> > My point is quite simple:
> > my_deviceA_init() {
> >         err = request_firmware(&fw, "deviceA"); <--- (a)
> >         if (err)
> >                 goto err_request;
> > 
> >         err = verify_firmware(fw);  <--- (b)
> >         if (err)
> >                 goto err_verify;
> > 
> >         load_fw_to_deviceA(fw);     <--- (c)
> >         ...
> > }
> > 
> > As legacy device drivers does not have (b), there is no chance to
> > prevent loading a firmware at (c) for locked-down kernel.
> 
> Ah, I think your example requires another piece of code to make it clearer.
> Here is an example legacy driver:
> 
> my_legacy_deviceB_init() {
>         err = request_firmware(&fw, "deviceB"); <--- (a)
>         if (err)
>                 goto err_request;
> 
>         load_fw_to_deviceA(fw);     <--- (c)
>         ...
> }
> 
> There is no verify_firmware() call here, and as such the approach Linus
> suggested a while ago cannot possibly fail on a "locked down kernel", unless
> *very* legacy API call gets a verify_firmware() sprinkled.
> 
> One sensible thing to say here is then that all request_firmware() calls should
> just fail on a "locked down kernel", however if this were true then even calls
> which *did* issue a subsequent verify_firmware() would fail earlier therefore
> making verify_firmware() pointless on new drivers.

As long as these "*very* legacy API calls", are calling
kernel_read_file_from_path() to read the firmware, there shouldn't be
a problem.

Mimi