Inspect BIOS Tables Safely with biosdecode

By the end of this guide, you will be able to run biosdecode against the firmware interfaces available on a Linux machine, recognise a permissions or device-access failure, and decide when dmidecode is the better tool. The examples target dmidecode 3.5, installed here as package version 3.5-3ubuntu0.1.

Allow about 10 minutes. You need a shell, the dmidecode package, and usually elevated privileges for the actual memory read. The command only reports firmware tables; it does not update the BIOS or change kernel settings.

Checkpoint: confirm the installed command

1. Check the version and help text

Start with two read-only checks. They confirm which executable will run and which options this installed build accepts.

$ command -v biosdecode
/usr/sbin/biosdecode
$ biosdecode --version
3.5
$ biosdecode --help
Usage: biosdecode [OPTIONS]
Options are:
 -d, --dev-mem FILE     Read memory from device FILE (default: /dev/mem)
     --pir full         Decode the details of the PCI IRQ routing table
 -h, --help             Display this help text and exit
 -V, --version          Display the version and exit

The version matters when comparing output with another machine or an upstream report. Do not copy options from a different release without checking this help text first. This build has one special mode, --pir full, rather than a general verbosity switch.

Checkpoint: know what will be read

2. Run the normal decoder

With no options, biosdecode reads the BIOS memory device at /dev/mem and prints the entry-point structures it recognises. The manpage lists SMBIOS, legacy DMI, SYSID, PNP, ACPI, BIOS32, PIR, 32OS, SNY, VPD and Fujitsu-specific FJKEYINF structures. The exact sections and values depend on the firmware and the access policy of the running kernel.

Use sudo for the normal diagnostic attempt when your account cannot read the device:

$ sudo biosdecode

A successful run prints decoded structures, but there is no single universal output to compare against. Save a review copy only where the contents are permitted to leave the machine, because firmware tables can include identifying inventory data.

$ sudo biosdecode > biosdecode.txt
$ sed -n '1,80p' biosdecode.txt

Do not treat an empty result as proof that the machine has no firmware tables. The command may lack access, the firmware may expose a format it does not decode, or the kernel may restrict legacy memory access.

3. Diagnose a failed access attempt

Run the same command without sudo if you want to see the account-level boundary, then repeat it with elevation. On this host the unprivileged attempt reports:

$ biosdecode
Can't read memory from /dev/mem
# biosdecode 3.5

This is an access failure, not a BIOS decoding result. Check the device path and permissions before changing anything:

$ stat -c '%A %U %G %n' /dev/mem
crw-r----- root kmem /dev/mem
$ sudo biosdecode --version
3.5

There is no recovery action inside biosdecode for a restricted /dev/mem. Do not loosen device permissions or disable kernel protections just to make a report work. If an elevated run still fails, record the exact error, kernel version and firmware vendor for the system owner. Those details are more useful than a speculative permission change.

Checkpoint: use an alternate input only for testing

4. Supply a different memory device deliberately

The -d or --dev-mem option accepts a file and defaults to /dev/mem. It exists for controlled diagnostics, not for making arbitrary files look like firmware.

$ biosdecode --dev-mem /dev/null
/dev/null: Unexpected end of file
# biosdecode 3.5

This safe test demonstrates that the option is being parsed, while /dev/null contains no BIOS data. Never point it at an untrusted file and assume that decoded text is genuine hardware information. If a vendor or test harness gives you a capture, verify its provenance and permissions before reading it.

5. Decode the PCI IRQ routing table

Use the only supported PIR mode when you specifically need PCI interrupt-routing details:

$ sudo biosdecode --pir full

The option does not mean "show everything". It selects detailed decoding of a PCI IRQ routing table, and the value full is required by this version. If the firmware has no readable PIR table, expect an error or no useful PIR section. Keep the normal run separate from this one so that an absent PIR table is not mistaken for a complete decoder failure.

Checkpoint: choose the right level of detail

6. Switch to dmidecode for hardware inventory

biosdecode is an entry-point inspector. Its own manpage warns that it can show too many addresses or too little detail because it does not follow pointers or provide lookup tables. For readable SMBIOS or DMI records such as system manufacturer, BIOS revision, board model or serial number, use dmidecode instead:

$ sudo dmidecode --type bios
$ sudo dmidecode --string system-product-name
$ sudo dmidecode --string bios-version

These commands may expose serial numbers and other sensitive inventory values. Keep the output local unless you have a clear reason and approval to share it. The result is also firmware-reported data, so confirm important facts against the machine or vendor documentation rather than treating it as unquestionable truth.

Common traps

• Confusing version output with a decode. --version never reads firmware tables; it only reports the program version.
• Assuming root fixes every failure. Root may still be blocked by kernel policy or by firmware that does not expose a readable table.
• Expecting stable text. Addresses, entry types and sections vary between machines and firmware revisions.
• Using --pir as a verbosity flag. Only --pir full is supported, and it targets PCI IRQ routing.
• Sharing raw output casually. Prefer a narrow dmidecode --string query when one value is all you need.

Done means

• You confirmed the installed version and accepted options.
• You know whether the normal command can read /dev/mem.
• You can use --dev-mem and --pir full without confusing their purposes.
• You use dmidecode for detailed, targeted SMBIOS values.
• You have not changed device permissions, firmware or kernel security settings.