Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
Mimi Zohar
zohar at linux.vnet.ibm.com
Fri Nov 10 13:45:06 UTC 2017
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
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list