[ On Friday, August 23, 2002 at 09:30:16 (-0700), Matthew Jacob wrote: ]
> Subject: Re: Where to put firmware?
>
> 
> I fail to see why lkms are less secure than loading
> from the filesystem other than the supposed 'better' authentication done
> in userland.

#1 -- more files to check for integrity (mistakes happen, even with
      automation)

#2 -- often the mechanism can't itself be unloaded (yes, it can be
      turned off sometimes, but it still sits there ready to exploit,
      and there are already lots of cracker tools which show how to use
      such a mechanism to avoid intrusion detection -- it's a real threat)

#3 -- much more complexity (reliability is a security issue)

I'm sure there are more, but these jump immediately to mind.

What's wrong with creating a single proper kernel binary image and
loading it once from the boot loader?  Once you've tested it then all
you need to know to be assured about its reliability is that the one
file it is contained in has not changed in any way since the tests and
that it can still be read successfully and completely by the bootloader.

And as for device firmware, well there are no good reasons I can think
of for wanting to use an LKM to load it -- that's just a very poor
excuse, possibly based on being too lazy to fix a driver which currently
hard codes the firmware image inside a static buffer that would
otherwise be "locked" within the static kernel binary image.  Meanwhile
there are a plethora of better (and overall simpler) ways to transfer
data from the filesystem to a device.

And the ordering problem does not really exist unless the device in
question is the one from which the initial kernel image must be loaded
-- everything else is just a small matter of programming in userland.
If though the device is the one the kernel image must come from then the
boot loader needs to load at least a minimal form of the firmware, so
then the question becomes one of whether the firmware (possibly a new
version) can be reloaded in the device once the kernel has started,
and/or what other secondary storage the bootloader can access, etc.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>