[unisog] Dell BIOS updates and non-"Dell" operating systems

Alan Amesbury amesbury at oitsec.umn.edu
Fri Oct 28 21:36:16 GMT 2005

[OK, this is a long one, but it's largely because of the background (and
maybe the formatting).  Apologies in advance.]

Recently I've hit a minor snag regarding the BIOS and firmware updates
to the various Dell servers I manage.  Most of our systems were
purchased from Dell without an operating system; those that we were
unable to purchase in that manner were ordered with Linux and promptly
wiped on arrival.  We are, by and large, a FreeBSD shop, an OS that
Dell, as an entity, barely knows exists.  This is all fine, as we don't
particularly want Dell to provide support for the OS on our systems. 
However, we're pretty interested in having them support the *hardware*
they've sold us, which includes providing updates/fixes to various
firmware-type things, such as the system BIOS, hardware RAID
controllers, etc.

There are three forms in which these updates can appear which Dell
demonstrably supports in one form or another.  They are:

    Raw, standalone binary - The update process requires that
       the binary be copied to bootable media and executed in
       a DOS-compatible environment.  This works great, as I
       have a bootable DOS floppy image and my OS understands
       the DOS filesystem just fine.  The BIOS update for the
       Precision 470 workstation is available in exactly this
       form.  It is identified as the "Windows/DOS" file format.

    Raw floppy image - I haven't found firmware updates in this
       form, but Dell knows about it.  They provide their 32-bit
       diagnostics utility (non-GUI version) in this form,
       wrapped in a tar.gz file.  Their instructions say to use
       'dd' to write this file directly to a floppy, a la
       "dd if=filename.img of=/dev/fd0" (process may vary by
       platform, something also noted in the instructions).
       Dell calls this the "GNU-Zip" format.

    ISO image - Dell provides firmware updates in ISO form, but
       they haven't updated the ISO image in about a year.  The
       PE650 and PE750 updates aren't included, and a couple
       important firmware updates for the PERC3/Di hardware
       RAID controller are missing.  I'm not sure if this is an
       officially supported format for BIOS updates.  However,
       the 32-bit diagnostics are also provided in ISO form,
       and there's a clear set of instructions concerning its
       use; Dell clearly understands what ISO images are.
       Dell calls this "ISO Image" format.

Pretty self-explanatory.  However, the majority of the firmware updates
Dell provides rely instead on having Windoze or Linux available.  The
two most prevalent examples of this are:

    Shell with binary payload - This firmware update package
       takes the form of a Bourne shell script with some sort of
       binary payload appended to it.  It doesn't execute under
       FreeBSD, as it appears to rely on command-line utilities
       present (only?) in RedHat.  After some massaging, I
       determined that the binary payload is maybe some sort of
       gzip'ed tarball.  However, I didn't see anything indicating
       it was something I could use under FreeBSD without adding
       the Linux emulation layer (not going to happen on our
       production systems!).  Dell calls this the "Update Package
       for RedHat Linux" format.

    Windoze executable with binary payload - This rather ominous
       sounding format consists of a Windoze executable that
       pops up a dialog box asking for a preformatted floppy,
       waits for you to click a button, then dumps the binary
       payload to floppy.  Aside from the superfluous UI features,
       this appears to be somewhat similar to what 'dd' does.
       Lacking a suitable emulation environment, this won't run
       on my FreeBSD systems either.  Dell calls this the "floppy"
       format, something of a misnomer.  The vast majority of Dell's
       updates, including those for systems ordered and shipped
       with no operating system, appear in this form.

The obvious problem here is that Dell, in spite of selling systems
without an operating system, expects people to be running RedHat Linux
or Windoze.  To date, aside from help provided by some Dell techs (who
may have arguably departed from Dell's support process), I've had an
extremely hard time getting BIOS/firmware updates in a form that I can
use.  What I don't understand, however, is why Dell doesn't simply stick
with providing BIOS updates in one of the three forms I describe above,
particularly the floppy or ISO image format.  Dell reps have repeatedly
driven home the point that ""Dell doesn't and isn't prepared to support
[insert non-RedHat, non-Windoze OS name here]."  However, I'm pretty
sure Dell expends some resources to ensure that their
Windoze-executable-with-binary-payload program works with all versions
of Windoze that Dell sells, which has to take some effort.  Also, that
rather creative Bourne-shell-with-binary-payload didn't write itself. 
Besides, since we're talking about BIOS/firmware updates, it seems that
Dell should try to take complete creative control and eliminate *all*
possible issues that a given host's OS might introduce.

In a way, Dell is already doing this.  The
Windoze-executable-with-binary-payload update creates bootable floppy
disks.  My request to Dell is that, instead of giving me the raw floppy
image wrapped up in some sort of Windoze-based floppy-writing utility,
they give me the raw floppy image by itself.  In that form, I'd be able
to burn it to floppy using just about any OS I could run on their
hardware.  If feeling particularly creative, I could use that old
Powerbook G3 running Debian we've got hanging around somewhere.  My
point is that they'd be better able to support *all* their customers,
not just the ones who run Dell-specific versions of Linux and Windoze. 
(We can't possibly be the only ones who ordered bare hardware!)

Then there's some security issues to consider.  I've worked in an
environment where policy prohibited the transfer and execution of
software from a floppy on highly sensitive systems if that floppy had
been used in another, less sensitive system.  Executables obtained
directly from the manufacturer for routine maintenance were allowed,
however.  While the level of protection I try to apply to my core
systems isn't quite *that* stringent here, I like the principle involved
and do try to stick with it.  The idea of running software on my core
hosts that's been on a Windoze box really doesn't appeal to me.  Yes,
this is arguably paranoid... but as a security guy I'm not medicated for
my paranoia.  I'm paid for it.  :-)

This afternoon I got a surprise visit from Kirk Amrhein ("Account
Executive, Higher Education," and Dell rep for umn.edu, uiowa.edu, and
several other schools in the upper Midwest) who assured me that Dell
understood my request, but was pretty sure that Dell wasn't going to do
much to accommodate "just one guy."  He did suggest, though, that if I
knew of others who were interested in this, that--well, it boils down to
"more voices" == "Dell hears better."  However, without any interest at
all, he figured it would be a minimum of a year or two before Dell
considered doing anything about it.

So, does anyone else out there have any interest in getting updates from
Dell in a more platform-agnostic form?  If so, and you're willing to let
Dell know that, please contact me off list.  I'm also interested in
hearing about reliable hardware vendors who don't have this problem and
make hardware compatible with FreeBSD, so if you know of any of those
(e.g., Iron Systems?), I'd appreciate hearing about them, too.

As always, thanks for taking the time to read this.

Alan Amesbury
(working but not speaking for the) University of Minnesota

More information about the unisog mailing list