summaryrefslogtreecommitdiff
path: root/dmidecode.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* 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-201-2/+12
| | | | | | | | | | 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-201-18/+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>
* 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-161-22/+28
| | | | | | | | | 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>
* 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>
* dmidecode: Save the CPUID formatJean Delvare2022-05-201-4/+6
| | | | | | | | | 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>
* dmidecode: Make dmi_print_cpuid more flexibleJean Delvare2022-05-201-24/+25
| | | | | | Let the caller choose which printing helper function will be used. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Helper function to print CPUIDJean Delvare2022-05-201-53/+63
| | | | | | | | Split the printing of the CPUID into a human-friendly way to a separate function. That way, it can be reused for other record types as needed. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Split CPUID type detection from dmi_processor_idJean Delvare2022-05-201-114/+133
| | | | | | | Move the code which decides the CPUID type to a separate function, so that it can be called from a different context. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: dmi_processor_id: Don't set the same variable twiceJean Delvare2022-05-201-1/+0
| | | | Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Don't display the raw CPU ID in quiet modeJean Delvare2022-05-201-2/+3
| | | | | | | It has little value on supported systems as we decode the same information in a more human-friendly way immediately after. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Support new byte value of Processor Upgrade field from SMBIOS 3.5.0Coiby Xu2021-10-211-2/+3
| | | | | | | | | | | Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz has byte value 3Fh which means Socket LGA4677 for Processor Information - Processor Upgrade field. [JD: Fix upper array boundary check.] Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Support new format of Processor ID from SMBIOS 3.4.0Nhi Pham2021-09-211-10/+47
| | | | | | | | | | | | For ARM64-class CPUs, the format of the Processor ID field depends on the processor's support of the SMCCC_ARCH_SOC_ID architectural call. This supports decoding the Processor ID correctly in case the SoC ID is supported. This patch should work for ARM32-class CPUs also. [JD: Simplify boolean test.] Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Fix crash with -u optionJean Delvare2021-01-191-1/+1
| | | | | | | | | | A segmentation fault was reported with option -u. Turns out to be a stupid thinko where the buffer offset was reset at the wrong loop depth. Reported-by: Jerry Hoemann <jerry.hoemann@hpe.com> Fixes: da06888d08b9 ("dmidecode: Use the print helpers in dump mode too") Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Make dmi_print_memory_size globalJerry Hoemann2021-01-151-1/+1
| | | | | | | | Make dmi_print_memory_size() global so that it can be called from outside of dmidecode.c. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Fix format warningsJean Delvare2021-01-151-7/+7
| | | | | | | | | Use the appropriate format specifiers to make the compiler happy. This fixes support ticket #110421: https://savannah.nongnu.org/support/index.php?110421 Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Set vendor earlyJean Delvare2021-01-151-5/+45
| | | | | | | | | | If OEM type entries come before the type 1 entry (System Information), we aren't able to decode them because we don't know the vendor yet. To fix this, figure out the vendor during a first pass, and walk the table again once we have the information. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reported-by: Erwan Velu <e.velu@criteo.com>
* dmidecode: Fix the condition error in ascii_filterTianjia Zhang2021-01-051-1/+1
| | | | | | | | The normal printable ASCII range is 32 to 127 (not included), so fix the error in this if condition. Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Use _dmi_string for dmi_set_vendorJean Delvare2020-12-101-1/+2
| | | | | | | | | The strings passed to dmi_set_vendor will never be printed, they are used for comparison purposes only, so the pre- and post-processing done by dmi_string is not needed. Call _dmi_string instead, which is faster. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Missing comma in the dmi_slot_type()Lianbo Jiang2020-12-101-2/+2
| | | | | | | | | | | | | In the initialization of "type", a suspicious concatenated string "PCI Express Mini 76-pinPCI Express 4 SFF-8639 (U.2)" is produced due to a missing comma between lines. [JD: Fixed a similar bug in dmi_processor_characteristics.] Fixes: b289de9deb32 ("Add new processor characteristics bits from SMBIOS spec 3.4.0") Fixes: c54348130a2a ("dmidecode: Add new system slot types from SMBIOS spec 3.4.0") Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Some OEM records require Product NameJerry Hoemann2020-11-301-2/+2
| | | | | | | | | Decoding of OEM records can depend upon the product in addition to the manufacturer. So, save "Product Name" from type 1 record in addition to "Manufacturer" in dmi_set_vendor. Signed-off-by: Jerry Hoemann <jerry.hoemann@hpe.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Skip details of uninstalled memory modulesJean Delvare2020-10-301-0/+3
| | | | | | | | | | | If a memory slot is empty then by definition the fields containing the memory module details are irrelevant. Best case they are filled with "Unused" and "None", but in some cases they are even invalid because the manufacturer did not bother setting the fields to valid neutral values. So it is better to not print these fields at all, so as to not confuse the user. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Add new processor characteristics bits from SMBIOS spec 3.4.0Prabhakar pujeri2020-10-231-2/+4
| | | | | * The bit to indicate 128-bit capable processor * The bit to indicate processor supports returning ARM64 SoC ID
* dmidecode: Add new system slot types from SMBIOS spec 3.4.0Jean Delvare2020-10-211-6/+20
| | | | | | | | | Based on an earlier patch from Prabhakar Pujeri (Dell). Version 3.4.0 of the SMBIOS specification adds 14 new system slot types and updates 2 (DMI type 9). Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Handle memory module extended speed fieldsJean Delvare2020-10-211-6/+20
| | | | | | | | | These fields were added by SMBIOS version 3.3.0. and although there is no hardware fast enough to need them yet, we can support them already. I missed them before because their addition is not mentioned in the specification change log. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Add new slot characteristics2 from SMBIOS spec 3.4.0Prabhakar pujeri2020-10-191-2/+5
| | | | | | * The bit to indicate PCIe surprise removal support. * The bit to indicate Flexbus CXL 1.0 version. * The bit to indicate Flexbus CXL 2.0 version.
* Add new processor upgrades from SMBIOS spec 3.4.0Prabhakar pujeri2020-10-191-2/+4
| | | | Added 2 more new values (0x3D and 0x3E).
* Add new memory device types from SMBIOS spec 3.4.0Prabhakar pujeri2020-10-191-2/+4
| | | | Added 2 more new values (0x22 and 0x23).
* dmidecode: Fix typos in commentsBastien Nocera2020-10-191-4/+4
|
* Pretend to support SMBIOS version 3.3.0Jean Delvare2020-10-141-1/+1
| | | | | | | | Even though we do not fully support SMBIOS version 3.3.0 yet, the missing parts are not even in the works, and I have yet to see an actual system needing them. So stop warning the users. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* Revert "updating system slot types with smbios spec 3.4.0"Jean Delvare2020-10-141-9/+6
| | | | | | | This reverts commit 85a05114311a78c493eeb6c9b664b22c0d1c2e35. This change was not properly reviewed before being committed and introduces a regression, in addition to having coding style issues.
* Revert "fix: Memory Technology <OUT OF SPEC> when slot is empty"Jean Delvare2020-10-141-5/+3
| | | | | | | This reverts commit 92853b621ff72e3ba87e0ed7675d2103d05b8d3c. This is not a bug in dmidecode. It is the BIOS' responsibility to encode the memory technology to 0x02 for "Unknown" when a slot is not in use.
* fix: Memory Technology <OUT OF SPEC> when slot is emptyPrabhakar Pujeri2020-10-131-3/+5
| | | | According to SMBIOS spec 3.4.0 Table 75 – Memory Device (Type 17) structure if the size of the memory device is 0 then we should consider the slot is empty
* updating system slot types with smbios spec 3.4.0Prabhakar Pujeri2020-10-131-6/+9
| | | | In SMBIOS SPEC 3.4.0 section 7.10.1 System Slots — Slot Type some of fields are missing in current dmidecode source.
* dmidecode: Update copyright yearJean Delvare2020-04-011-1/+1
|
* dmidecode: White space fixesJean Delvare2020-04-011-2/+2
|
* dmidecode: Add helper function for structure errorsJean Delvare2020-04-011-1/+1
| | | | | | | Add a helper function to print structure errors, specifically for structures which do not fit in the table. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Add helper function for separatorsJean Delvare2020-04-011-4/+5
| | | | | | A simple helper function to print a blank line between records. Signed-off-by: Jean Delvare <jdelvare@suse.de>
* dmidecode: Use the print helpers in dump mode tooJean Delvare2020-04-011-12/+18
| | | | Signed-off-by: Jean Delvare <jdelvare@suse.de>
View Lorry Controller Status