I hope this isn't too much flame-bait. I really don't want to throw any
gasoline on the fire. But please, do not just instantly hit "Reply" and
start blasting away without reading it through first. :-)
I've been following all this over the past few days, and my opinion (if
anyone cares) is as follows:
1) normal interfaces to hardware governed by a spec. should only allow
spec-compliant commands to be sent to the device. This protects both
the OS and the hardware from "accidents". (not from intentional attacks)
2) for the purposes of this discussion, don't consider security except
from the standpoint of "normal, ungodlike users should only be allowed
to play fair. Once root is compromised, all bets are off". Compromise
of root is not typically for something this close to hardware to worry
about anyway. Just trust that the rest of the system is doing its job &
you've got a sane admin & some sort of physical security).
3) Because manufacturers like to issue firmware updates in the form of
.zip downloads these days, some method must exist for these or something
like them to be utilized.
4) a normal, mortal user should not be able to update firmware. Only
root should be able to do this.
5) a firmware update should not require you to boot off a diskette, and
whatever mechanism is used should be open and cross-platform if it is to
succeed.
Therefore, I think that the answer lies somewhere down the path of
creating a root-access-only interface and utility that will allow
updates. With co-operation from hardware manufacturers, this would be
pretty simple. How do you keep the script-kiddies from using this to
hurt you once they've compromised root? Well, you can't completely, but
digital signatures can help:
signed firmware update --> utility --> interface
interface --> hardware (hardware checks sig & if ok sends one back)
hardware --> interface --> utility (checks hardware sig vs. table of
valid sigs
specified in the firmware update)
is valid? yes, then command the hardware to get ready for an update &
start updating.
no, then print "You lose. Play again?" and exit.
Obviously this is very high level. This needs to be generic, so that
the vendor can
supply the commands to be sent, etc.
I think the 2 digital signatures will help out some, though it would
just be a matter of time before someone finds the vendor signature & the
device signatures and starts messing around. This way at least, the
kernel doesn't need to provide much. It puts the onus on the hardware
manufacturer to validate their firmware updates. All we would need to
provide is a mechanism by which they can push their data down to the
hardware.
User (must be root) would have to provide what device to work on (if you
are like me and all your drives come from Maxtor, for instance), a'la:
firmupgrade /dev/mydev package.crypto.zip [maybe a 3rd key?]
This has its own weaknesses, but in the absence of jumpers (In a way,
I'm glad to see jumpers disappear...it was always a pain to open my box,
move cables, finally find the blasted scsi card, etc.), *something* must
be done. I personally think we need some hardware industry buy-in, to
make a nice open interface, supported not only on Linux, but Be,
win-whatever-year-it-is, Mac, OpenStep, AIX, *BSD, you-name-it. Such a
thing will take time to develop, but I think that since we've seen the
need, we should be leading the effort. Each OS would have to provide
something that reads these update files and does what they ask. Whether
that is just a userland utility (as it would certainly be on a MS
product, except maybe NT) or a combination utility & interface (as I
propose) would be up to the OS designers. Hardware stays out of our
land, we stay out of theirs. We just try to cover each other's back a
little bit.
This was not intended to be the be-all, end-all solution...just
something to steer conversation a little back into the "what can we, as
developers of the best OS in the free world, do to fix the current
situation?" I believe I've seen some comments to this end, but nobody's
come out to propose anything.
Discuss amongst yourselves... :)
-- Regards,Darin W. Smith
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST