lkml.org 
[lkml]   [2017]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
From
Date
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

\
 
 \ /
  Last update: 2017-11-10 14:46    [W:0.245 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site