summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Move function dmi_hp_240_attr() where it belongsHEADmasterJean Delvare2023-05-021-21/+21
|
* dmioem: Decode HPE OEM Record 197Jerry Hoemann2023-05-021-0/+80
| | | | | | | Decode HPE OEM Record 197: Processor Information Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Don't read beyond sysfs entry point bufferJean Delvare2023-04-261-12/+12
| | | | | | | | | | | | | | | | | | | | | Functions smbios_decode() and smbios3_decode() include a check against buffer overrun. This check assumes that the buffer length is always 32 bytes. This is true when reading from /dev/mem or from a dump file, however when reading from sysfs, the buffer length is the size of the actual sysfs attribute file, typically 31 bytes for an SMBIOS 2.x entry point and 24 bytes for an SMBIOS 3.x entry point. In the unlikely event of a malformed entry point, with encoded length larger than expected but smaller than or equal to 32, we would hit a buffer overrun. So properly pass the actual buffer length as an argument and perform the check against it. In practice, this will never happen, because on the Linux kernel side, the size of the sysfs attribute file is decided from the entry point length field. So it is technically impossible for them not to match. But user-space code should not make such assumptions. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Consistently use read_file() when reading from a dump fileJean Delvare2023-04-261-2/+9
| | | | | | | | | | | | | | | | Use read_file() instead of mem_chunk() to read the entry point from a dump file. This is faster, and consistent with how we then read the actual DMI table from that dump file. This made no functional difference so far, which is why it went unnoticed for years. But now that a file type check was added to the mem_chunk() function, we must stop using it to read from regular files. This will again allow root to use the --from-dump option. Signed-off-by: Jean Delvare <jdelvare@suse.de> Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Update HPE OEM Record 216Jerry Hoemann2023-04-071-1/+2
| | | | | | | | New firmware type. (Also remove non-ASCII character in string literal.) Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 238Jerry Hoemann2023-04-071-0/+2
| | | | | | | Add new location. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 236Jerry Hoemann2023-04-071-0/+1
| | | | | | | | Record type deprecated for Gen11. If record number reused in future, it will have a different decoding. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 212Jerry Hoemann2023-04-071-0/+1
| | | | | | | | Record type deprecated for Gen9. If record number reused in future, it will have a different decoding. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 221Jerry Hoemann2023-04-071-0/+1
| | | | | | | | Record type deprecated for Gen8. If record number reused in future, it will have a different decoding. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 203Jerry Hoemann2023-04-071-1/+11
| | | | | | | Add new device locations and flag value. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Decode HPE OEM Record 239Jerry Hoemann2023-04-031-0/+127
| | | | | | | Decode HPE OEM Record 239: USB Device Correlation Record. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Recognize Gen 11 systemsJerry Hoemann2023-04-031-1/+2
| | | | | | | Add G11 to dmi_hpegen_t. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: HPE OEM Record 237 Firmware changeJerry Hoemann2023-04-031-3/+5
| | | | | | | | | HPE OEM record type 237 offset 0x09 field was changed from a single byte STRING to a two byte WORD representing date. Fixes: cdab638dabb7 ("dmioem: Decode HPE OEM Record 237") Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Use -DALIGNMENT_WORKAROUND on arm as wellJean Delvare2023-04-031-1/+1
| | | | | | | | | The OBS armv7l build log shows a lot of warnings about casts increasing the required alignment of target type. This suggests that this architecture needs to use the slower byte access which is enabled by -DALIGNMENT_WORKAROUND. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Set the version to 3.5dmidecode-3-5Jean Delvare2023-03-142-1/+15
| | | | Update the NEWS file accordingly.
* Fix a build warning when USE_MMAP isn't setJean Delvare2023-03-141-1/+3
| | | | | | | | | | | | Building with USE_MMAP unset results in the following warning: util.c:158:13: warning: ‘safe_memcpy’ defined but not used [-Wunused-function] static void safe_memcpy(void *dest, const void *src, size_t n) ^~~~~~~~~~~ Only define the function when USE_MMAP is set. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: HPE type 242: Fix ID on 32-bit systemsJean Delvare2023-03-101-1/+1
| | | | | | | | | | | | | | I noticed that the reported ID is different when building dmidecode in 32-bit mode. The reason is that %lx isn't a valid format to print a 64-bit integer. It works by accident on 64-bit systems because types "long integer" and "long long integer" are the same there, but on 32-bit systems, only the latter can actually store a 64-bit value. Change the format to %llx so that it works on 32-bit systems too. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 90d1323a8d14 ("dmioem: Decode HPE OEM Record 242") Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
* Ensure /dev/mem is a character device fileJean Delvare2023-03-101-12/+13
| | | | | | | | | | | | While option --dev-mem can be convenient for testing purposes, it could be abused by attackers to force dmidecode to read a malicious file. Add a safety check on the type of the mem device file we are asked to read from. If we are root and this isn't a character device file, then something is fishy and we better stop. For non-root users, reading from a regular file is OK and accepted. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Use the right variable for -s bios-revision/firmware-revisionJean Delvare2023-03-101-4/+4
| | | | | | | | | | | It turns out that variables "offset" and "key" have the same value for these lines of code, so there is no actual bug, nevertheless using the right variable makes the code more obviously correct, and less prone to introduce a bug later when adding support for new strings. Signed-off-by: Jean Delvare <jdelvare@suse.de> Tested-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmidecode: Do not let --dump-bin overwrite an existing fileJean Delvare2023-02-202-3/+14
| | | | | | | | | | Make sure that the file passed to option --dump-bin does not already exist. In practice, it is rather unlikely that an honest user would want to overwrite an existing dump file, while this possibility could be used by a rogue user to corrupt a system file. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmidecode: Write the whole dump file at onceJean Delvare2023-02-203-59/+51
| | | | | | | | | | | | | | | | When option --dump-bin is used, write the whole dump file at once, instead of opening and closing the file separately for the table and then for the entry point. As the file writing function is no longer generic, it gets moved from util.c to dmidecode.c. One minor functional change resulting from the new implementation is that the entry point is written first now, so the messages printed are swapped. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmidecode: Split table fetching from decodingJean Delvare2023-02-201-24/+62
| | | | | | | | | | | | | | | | Clean up function dmi_table so that it does only one thing: * dmi_table() is renamed to dmi_table_get(). It now retrieves the DMI table, but does not process it any longer. * Decoding or dumping the table is now done in smbios3_decode(), smbios_decode() and legacy_decode(). No functional change. A side effect of this change is that writing the header and body of dump files is now done in a single location. This is required to further consolidate the writing of dump files. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Avoid intermediate buffer (HPE type 216)Jean Delvare2023-02-041-28/+26
| | | | | | | | | | Print the "Version Data" attribute directly instead of relying on an intermediate buffer on the stack. While this slightly increases the binary size, this also makes the code faster, lowers the memory footprint, and avoids the risk of buffer overrun. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Decode HPE OEM Record 216Jerry Hoemann2023-02-031-0/+200
| | | | | | | Decode HPE OEM Record 216: Version Indicator Record. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Drop the CPUID exception listJean Delvare2022-12-161-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in 2003, I had a system where the CPU type was not set. I added a quirk so that it would still be recognized as x86, and the CPUID could be decoded. A few more exceptions where added over the years, but in effect, the list was last modified in 2008. Having such an exception list isn't actually a good idea, for the following reasons: * It requires endless maintenance work if we want to keep it up-to-date. * It adds some (admittedly minimal) burden to the sane systems. * If we were to add more entries to the exception list, it wouldn't scale well (linear algorithmic complexity). This could be improved but at the cost of more complex code. * It sends the wrong message to the hardware manufacturers ("You can get things wrong, we'll add a workaround on our side.") Therefore I would like to get rid of this exception list. Doing so has the nice side effect of simplifying the code and making the binary smaller. If anyone really needs the CPUID information on such non-compliant systems, there are other ways to retrieve it, such as lscpu or /proc/cpuinfo. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Add a --no-quirks optionJean Delvare2022-12-164-22/+39
| | | | | | | | | This new option is aimed at firmware developers to help them validate their work. When this option is used, quirks and fixups are disabled in dmidecode, which will dumbly decode everything found in the table even if it is known to be incorrect. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Fortify entry point length checksJean Delvare2022-12-161-2/+8
| | | | | | | | | | | Ensure that the SMBIOS entry point is long enough to include all the fields we need. Otherwise it is pointless to even attempt to verify its checksum. A similar check was added to the SMBIOS entry point parser in the Linux kernel. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Typo fix (Virutal -> Virtual)Mike Gabriel2022-12-021-1/+1
| | | | | Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: 3e86b5d3a228 ("dmioem: Decode HPE OEM Record 203")
* dmioem: Decode HPE OEM Record 242Jerry Hoemann2022-10-111-0/+122
| | | | | | | Decode HPE OEM Record 242: Hard Drive Inventory Record Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Update HPE OEM Record 238Jerry Hoemann2022-09-221-1/+1
| | | | | | | | Spec was updated to clarify that the device is a USB Hub for NAND controller. Not the NAND controller itself. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Decode HPE OEM Record 230Jerry Hoemann2022-09-151-0/+53
| | | | | | | Decode HPE OEM Record 230: Power Supply Information Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Fix segmentation fault in dmi_hp_240_attr()Jean Delvare2022-09-091-2/+3
| | | | | | | | | | | | | | | | pr_attr() does not accept a NULL format string. glibc can deal with it, but FreeBSD's libc chokes on it. Display the attributes as a list instead. Pack the attribute name and status into a single formatted string that can be passed to pr_list_item(). That's arguably a hack, but it's cheap, non-intrusive, and works nicely in the end. Bug reported by Scott Benesh (Microchip). Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: a4b31b2bc537 ("dmioem: Present HPE type 240 attributes in a nicer way") Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Decode HPE OEM Record 224Jerry Hoemann2022-07-191-0/+120
| | | | | | | Decode HPE OEM Record 224: Trusted Module (TPM or TCM) Status (Type 224). Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* NEWS: Fix typoJean Delvare2022-06-271-1/+1
|
* Set the version to 3.4dmidecode-3-4Jean Delvare2022-06-273-1/+26
| | | | | Update the NEWS file accordingly, and the AUTHORS file as well to list all recent contributors.
* dmioem: Incorrect use of staticJerry Hoemann2022-06-181-5/+5
| | | | | | | | | | | The *str = "Reserved" is intended as the default value when index is outside of the array. str shouldn't retain values from an earlier invocation of the function. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Fixes: 3e86b5d3a228 ("dmioem: Decode HPE OEM Record 203") Fixes: 4d8bdbc8b287 ("dmioem: Decode HPE OEM Record 238") Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Set supported version to 3.5.0Jean Delvare2022-06-151-1/+1
| | | | | | | | While we do not support every piece of the specification yet, the most needed ones are in place now so it seems reasonable to stop warning users. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Drop outdated referencesJean Delvare2022-06-151-2/+2
| | | | | | | | | Types 126 and 127 are at the end of the list, their reference section changes as new structure types are being added to the specification. Just omit the section number for them, so that we don't have to update it with every new version of the specification. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Enumerate the new struct typesJean Delvare2022-06-151-2/+5
| | | | | | Add types 44, 45 and 46 to dmi_smbios_structure_type(). Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Add support for type 45 records (Firmware Inventory Information)Jean Delvare2022-06-151-0/+69
| | | | | | | SMBIOS specification 3.5.0 adds a new record type: Firmware Inventory Information. Add support for it. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Add new fields and enumerated values from SMBIOS 3.5.0Jean Delvare2022-06-151-9/+38
| | | | | | | | | | Version 3.5.0 of the SMBIOS specification added the following: * BIOS Information: Manufacturing mode flags * System Slots: Slot height field * Built-in Pointing Device: 2 new interface types * Onboard Devices Extended Information: 7 new device types Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Add missing bits from SMBIOS 3.4.0 specificationJean Delvare2022-06-151-2/+72
| | | | | | | | When adding support for SMBIOS 3.4.0, we missed new enumerated values for the slot type field, and 3 new fields at the end of System Slots (type 9) structures. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Make dmi_slot_bus_width() reusableJean Delvare2022-06-151-18/+34
| | | | | | | Let dmi_slot_bus_width() return its value without a trailing space, so that this function can be reused in a different context. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Decode HPE OEM Record 237Jerry Hoemann2022-06-081-0/+28
| | | | | | | Decode HPE OEM Record 237: DIMM Vendor Part Number Information. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Decode HPE OEM Record 194Jerry Hoemann2022-06-071-0/+21
| | | | | | | Decode HPE OEM Record 194: Super IO Enable/Disable Features. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Nicer display of PCI device (HPE type 238)Jean Delvare2022-06-031-3/+2
| | | | | | | | | Use the standard PCI device format (bus:dev.fn) to designate the parent PCI device of the USB port, so it is much easier to lookup in the output of lspci for example. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Decode HPE OEM Record 238Jerry Hoemann2022-06-011-0/+89
| | | | | | | Decode HPE OEM Record 238: USB Port Connector Correlation Record. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmioem: Fix HP type 203 preliminary checks and headerJean Delvare2022-05-251-2/+2
| | | | | | | | | | | | | Fix the preliminary check of HP type 203 records: * If generation is too old, return 0 so that the raw record will be displayed. * If length is too short, still print the record type header. This is how all other records are handled. Also drop the duplicate company name in the header. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com>
* dmioem: Decode HPE OEM Record 199Jerry Hoemann2022-05-241-0/+31
| | | | | | | | Decode HPE OEM Record 199: CPU Microcode Patch. Only G9 and later are supported. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Save the CPUID formatJean Delvare2022-05-202-4/+8
| | | | | | | | | In order to decode the information from HPE type 199 in a human-friendly way, we need to know how the CPUID data is encoded. This depends on the CPU brand and family, so save this information for later. Signed-off-by: Jean Delvare <jdelvare@suse.de>
View Lorry Controller Status