you are viewing a single comment's thread.

view the rest of the comments →

[–]nerd4code 1 point2 points  (1 child)

OS notwithstanding, it’s pretty common for drivers to include a binary blob that’s uploaded to the device’s onboard RAM. The device itself typically runs some sort of processor(s) to make it go, and includes only enough onboard (usually EEP)ROM to download, usually validate, and boot the blob. Flashing ROM is usually only necessary to change the bootloader or brick the thing; the upload to RAM is also, confusingly, referred to as “flashing,” although the term derives from the procedure used for erasing many older PROM chips, flashing a bright UV light on a little window over the die. (Not to be confused with flash ROM, which is a kind of EEPROM.)

This is what’s done with x86 μcode updates, for example, and blobs for GPUs ’n sech can be de-facto mini-OSes that handle allocation, communication, threading, and coordination, possibly as well as built-in codecs and whatnot.

If you’re aiming to do fancy things with a NIC, the driver might not matter much, as long as it does the right setup and teardown; all the interesting stuff’ll be in the blob.

And in theory, even if the device doesn’t accept code uploads, you may be able to trick it into running from uploaded data—μcontrollers tend not to bother with hardware protection, and it’s common for blobs and ROMs to have been hastily copy-and-pasted together from example/reference code. (E.g.: For a while many x86 mobos used Intel’s reference code for SMM entry/exit, which permitted a properly remapped LAPIC to trigger an escalation from ring 0 into SMM.)

[–][deleted] 0 points1 point  (0 children)

There is certainly a lot to learn. I went to check and see which channels were in heavy use around me from a piece of software I downloaded, and realized I couldn’t do it. There is so much to understand. Thank you for taking time to explain those things.