Editing Hard Disk Firmware

Is FreeBSD capable of editing hard disk firmware?
I'd like to be able put some sort of label in the firmware if possible.
 
What?

Hard disk drives have firmware. It is actually very complex, and can have very dangerous bugs, there have even been reports of hacking / espionage exploits using hard disk firmware. Downloading firmware to hard disks is not an easy process, and requires typically vendor-specific workflows or tools. It can be done with explicit SCSI and SATA commands (for example with sg_utils), but is not trivial at all. Part of the process really should be to make sure you have a method in place to get firmware from a trustworthy source (for example: Seagate), and that it has not been tampered with before sending it to the drive.

However, disk drives don't have a mechanism for "labeling" them. Certainly, you can attach a physical paper label to the outside of the drive. You can write to the disk itself, and that often involves labeling (for example, with the GPT partitioning mechanism, you can give the partitions symbolic names, which makes them much easier to manage); to the disk drive, the partition table is nothing but data which happens to be written on the disk.

Can you please explain what you are trying to accomplish?
 
Why you need label? There is serial number which is unique. Make a table with S/N <=> your label.
 
Is FreeBSD capable of editing hard disk firmware?
I'd like to be able put some sort of label in the firmware if possible.
Most hard disk firmware is unique to each disk. It is writable because it stores data about where the 1st physical sector is, bad blocks, SMART information etc. It's possible to write to it, but chances are you'd brick your disk in the process.

You can have two identical disks but the firmware chip cannot be swapped between them.
 
Re/ upgrading disk firmware: It can be done from any OS that has full access to the SCSI/SATA stack. You need to send very specialized SCSI/SATA commands, in some unusual combinations. The way to do that is vendor specific; the documentation for how to upgrade firmware may to be under NDA (meaning not published to the general public, only accessible to large customers that have contractual relationships with the disk vendors).

Re/ Mark_J's comment: The firmware itself is not disk specific, but model specific. If you have a model ABC123XYZ, there will be a firmware package for that model, and it can be downloaded to any disk of that model. The disk-specific information (as you said: track and sector locations, bad block maps, SMART, but even more importantly zone mapping) is stored in similar places on the drive, but is not part of the firmware. However, that information may be stored on the same physical media (chip or ... see below), so replacing the flash chip may wipe out two things.

In some disks, only a small fraction of the firmware is stored in flash chips. The remainder is stored on the spinning disk itself. Typically that works by having some "hidden" cylinders or zones on the disk, which are written at low density. The boot firmware for the drive is in a flash chip, and it can read those firmware hidden zones, without needing high-performance or high-density optimizations. But

And bricking disks by updating firmware is unfortuantely common. I would recommend that anyone who regularly updates disk firmware have a very good relationship with disk vendor's engineering departments, to get disks unbricked.
 
This sort of work of updating the drive firmware is performed by the vendor on their preferred platform by issuing updater software along with the firmware, often for MSDOS. To answer your question: capable? Probably not without a specialized driver.
 
While you are not wrong (this is *often* done by vendors, and *sometimes* using DOS), it can also be performed by any end user who knows how to do it, and who is willing to spend the week required to write the required software. There is no need for (kernel) driver development. Under Linux, you can get pre-built tools for some disk drive types (search the web for "Seatools" as an example); I've not seen such tools for FreeBSD.
 
Re/ Mark_J's comment: The firmware itself is not disk specific, but model specific. If you have a model ABC123XYZ, there will be a firmware package for that model, and it can be downloaded to any disk of that model. The disk-specific information (as you said: track and sector locations, bad block maps, SMART, but even more importantly zone mapping) is stored in similar places on the drive, but is not part of the firmware. However, that information may be stored on the same physical media (chip or ... see below), so replacing the flash chip may wipe out two things.

I guess I lost it in translation.

Each disk has a bios chip, this is a flash-memory chip which holds the firmware. This bios contains, among other things the driver code (firmware) for the disk model as well as unique data to locate the 'secret' system area on the hard disk. This area differs even on disks of the same model.

When you update the firmware, the 'driver code' is modified, nothing else. Bad block mapping, spin frequency etc is not modified as this is dependent on the disk itself.

How do I know this? Well, I've replaced a few shorted disks in my time. You swap the bios from the bad disk onto a replacement PCB and your disk is back in business. If you don't you get a non - functioning disk even with a replacement PCB.

So what I'm saying is, if you can grab the firmware, find a space in it not used by the vendor (if it exists), add your information into it, and re-flash it, then it's possible. Possible? But not probable. If you even overwrite one byte of information where it's not supposed to be, your disk is toast.
 
sysutils/sg3_utils allows some modifications to the drive configuration.
I remember I managed to convert originally fiberoptically connected SAS drive (in Advanced Format) to a more common 512-byte format and also changed the firmware on it. Did I use additional software for the latter I cannot recall. It was Seagate Cheetah 15k/rpm mech drive. I remember Windows utilities refused to interact with the drive.
 
It is much easier to find unused area (some bytes on first blocks) on the disk (not the firmware) and store the label there. The risk of problems is much lower.
 
Back
Top