so i have a few comments that mainly pertain to the documentation
of this functionality for driver writers.
the first is that since firmware will be deilvered wrapped in elf
files, on x86 systems driver writers should deliver two copies
of their firmware, one as a 32-bit elf file and the other as a 64-bit
elf file. this should be explicity mentioned in the documentation.
my second comment is that while i realize that one of the boundary
conditions of this case is:
This proposal does not provide ways to avoid name conflict
between the firmware image module. The module provider should
name it reasonably to avoid that.
i still think that this case should provide advice for naming firmware
files to driver writers. of example, should we create a firmware
directory for all firware files? or should firmware files have the
same name as the dirver but with some special extension?
lastly, until new boot on sparc integrates, there is no public way for
boot devices on sparc to access firmware files. the documentation
should probably mention this limitation.
ed
On Fri, Jun 15, 2007 at 01:44:05PM -0400, James Carlson wrote:
> I'm sponsoring this fast-track request for Freeman Liu. The timer is
> set to 06/22/2007. (A brief summary: 2005/050 interfaces are now
> Committed, patch/micro release binding.)
>
>
> Background
>
> Many hardware devices contain some software to function correctly.
> Traditionally, this piece of software was stored in non-volatile
> storage and thus called firmware. But recently, more and more
> hardware vendors replaced the non-volatile memory with volatile
> one to lower cost. For example, Intel 3945 wifi card and Intel
> wusb devices. And the "firmware", which comes in the form
> of an image file, now needs to be downloaded into the hardware
> before the hardware can fully function.
>
> Most of other main-stream OSes provide interfaces to access firmware
> in raw-data format. But the shortage of the raw-data format is that
> authentication check is not available. Therefore, we prefer to wrap
> the raw-data format firmware image in a kernel module so that we can
> sign and verify it by elfsign.
>
> In Solaris, the existing interfaces ddi_modopen, ddi_modsym and
> ddi_modclose serve this purpose very well. These interfaces have been
> used inside Sun for several cases including md, kcf and brandZ and are
> mature. However, these interfaces are private ones and can not be
> leveraged by hardware vendors and communities.
>
> This proposal is a follow up to "ddi_modopen dynamically
> access a loadable kernel module" (PSARC 2005/050). It is
> necessary to becoming familiar with that case to understand
> this issue.
>
> Competitive Analysis
>
> Windows provides interfaces to load firmware and sign at the package
> level. Windows requires all kernel components signed for the 64-bit
> platform. A signature can be stored in the .cat file of a package
> which contains the checksum of selected files in the packages.
>
> Linux adopts similar solution. For example, rpm provides signature
> function.
>
> Proposal
>
> We propose to make the interfaces ddi_modopen, ddi_modclose and
> ddi_modsym in 2005/050 Committed.
>
> We will use these interfaces to deliver separate firmware files on
> Solaris, and encourage other developers to use the interfaces in this
> way as well.
>
> Compared to other solutions, this proposal has many advantages.
> First, it can enable drivers to load and unload the image dynamically.
> This avoids unnecessary waste of ram. Second, because dependency can
> be set between drivers and the firmware image module, the potential boot
> device can rely on this to load firmware. Third, it can signed to
> ensure the authentication.
>
> This proposal requires a patch release binding so that it can be
> backported to S10 updates. But it will not be back ported to S9
> and earlier version for the same reason mentioned in 2005/050 that
> doing that requires many of the module loading bugs fixed in s10
> to be back ported too.
>
> Interfaces
>
> ------------------------------------------------------------------
> Interface Name Stability Comments
> ------------------------------------------------------------------
>
> KRTLD_MODE_FIRST Commited Mode argument to
> ddi_modopen(9F).
>
> ddi_modhandle_t Commited Opaque handle returned
> by ddi_modopen(9F).
>
> ddi_modopen(9F) Commited Peer of dlopen(3C)
>
> ddi_modsym(9F) Commited Peer of dlsym(3C)
>
> ddi_modclose(9F) Commited Peer of dlclose(3C)
>
> Prototypes (defined in modctl.h)
>
> #define KRTLD_MODE_FIRST 0x0001
>
> typedef struct __ddi_modhandle *ddi_modhandle_t;
>
> extern ddi_modhandle_t ddi_modopen(const char *modname,
> int mode, int *errnop);
>
> extern void *ddi_modsym(ddi_modhandle_t
> handle,
> const char *symname, int *errnop);
>
> extern int ddi_modclose(ddi_modhandle_t
> handle);
>
> #pragma unknown_control_flow(ddi_modopen, ddi_modsym, ddi_modclose)
>
> Documentation
> Manpage for ddi_modopen, ddi_modsym and ddi_modclose will be added.
>
> A section about "Dynamic module access functions" will be added to
> Appendix B of "Writing Device Drivers".
>
> The dynamic way to fulfill the dependency of modules will be added to
> the section "Module dependencies" of Chapter 20 of "Writing Device
> Drivers".
>
> Boundary Condition
> This proposal does not cover the case to upgrade firmware in
> non-volatile memory, such as flash. That always needs to stop
> the hardware and the upgrade process is usually done by a program
> provided by vendor.
>
> This proposal does not provide ways to avoid name conflict
> between the firmware image module. The module provider should
> name it reasonably to avoid that.
>
> This proposal does not cover the case to load raw-data format
> firmware.
>
> Reference
> http://sac.sfbay/PSARC/2005/050/
> RPM manpage: http://www.netadmintools.com/html/8rpm.man.html
> (Windows) Code Signing Best Practices:
> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
