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
