Before this change, `ipmitool` would not detect any checksum errors
in FRU areas when using 'fru print'. Now it will print whether the
area checksum is OK or INVALID for Chassis, Board, and Product areas.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
* Add a decoder for System Management records in
the Multirecord area
* Refactor GUID/UUID decoding: Use the same code for `mc guid`
and for `fru print` to decode the GUID and System Unique ID
in System Management records in the Multirecord Area.
* Fix some type errors in calls to printf/sprintf in GUID decoder
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Fix calculation of the buffer size for decoded 6-bit ASCII
strings. Previously the program could allocate too a short buffer
that caused buffer overflows and segmentation fault crashes on
certain FRU contents.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Unify the comparison idioms use.
Always use `if(!strcmp())` for "if string equals"
and `if(strcmp())` for "if string is not equal".
Never use `== 0` and `!= 0` with `strcmp()`.
Minor reformatting of the code immediately surrounding the
refactored lines.
Resolvesipmitool/ipmitool#104
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Clean up use of strcmp/strncmp/strncasecmp for command line arguments.
Never use anything but `strcmp()` unless absolutely neccessary.
Partialy resolvesipmitool/ipmitool#104
Final part of the fixes for CVE-2020-5208, see
https://github.com/ipmitool/ipmitool/security/advisories/GHSA-g659-9qxw-p7cp
9 variants of stack buffer overflow when parsing `id_string` field of
SDR records returned from `CMD_GET_SDR` command.
SDR record structs have an `id_code` field, and an `id_string` `char`
array.
The length of `id_string` is calculated as `(id_code & 0x1f) + 1`,
which can be larger than expected 16 characters (if `id_code = 0xff`,
then length will be `(0xff & 0x1f) + 1 = 32`).
In numerous places, this can cause stack buffer overflow when copying
into fixed buffer of size `17` bytes from this calculated length.
Partial fix for CVE-2020-5208, see
https://github.com/ipmitool/ipmitool/security/advisories/GHSA-g659-9qxw-p7cp
The `read_fru_area_section` function only performs size validation of
requested read size, and falsely assumes that the IPMI message will not
respond with more than the requested amount of data; it uses the
unvalidated response size to copy into `frubuf`. If the response is
larger than the request, this can result in overflowing the buffer.
The same issue affects the `read_fru_area` function.
ipmi_intf.h was missing a couple of declarations for the functions
used by fru, sdr and hpmfwupg modules. Add those declarations
to ipmi_intf.h and remove local declarations.
This fixes a couple of compilation warnings.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Swap calls to free() with calls to free_n() to leverage helper method
and handle clearing pointers after freeing in one step.
Signed-off-by: Patrick Venture <venture@google.com>
Check against FRU_AREA_MAXIMUM_BLOCK_SZ instead of FRU_BLOCK_SZ
when checking if the write chunk needs to be reduced.
Apparently, that was the original intention, and then there
was just a typo. In other places the same check is done properly.
Signed-off-by: Patrick Venture <venture@google.com>
Change ipmi_fru_query_new_value to return the bool type
instead of an int that's being used as a boolean value.
Signed-off-by: Patrick Venture <venture@google.com>
Add fru_cc_rq2big helper method to reduce duplicate
code checking for specific size-based IPMI response
codes.
Signed-off-by: Patrick Venture <venture@google.com>
Cleanup style in method ipmi_fru_oemkontron_get as well as add inverted
logic checks to reduce indentation.
Signed-off-by: Patrick Venture <venture@google.com>
Fixup the following array bounds checking bugs:
[lib/ipmi_fru.c:1003]: (style) Array index 'i' is
used before limits check.
[lib/ipmi_fru.c:1127]: (style) Array index 'i' is
used before limits check.
[lib/ipmi_fru.c:1262]: (style) Array index 'i' is
used before limits check.
Signed-off-by: Patrick Venture <venture@google.com>
Move static objects declared in headers to the source files where
they're used.
Partially resolvesipmitool/ipmitool#13
Signed-off-by: Patrick Venture <venture@google.com>
Cleanup all unused-parameter warnings. Each warning was examined to
verify it wasn't simply a case of a build macro difference.
Partially resolvesipmitool/ipmitool#13
Signed-off-by: Patrick Venture <venture@google.com>
Several functions were passed a struct ipmi_intf* even though it was
unused. This removes the unused parameters and changes calls and
signatures.
Partially resolvesipmitool/ipmitool#13
Signed-off-by: Vernon Mauery <vernon.mauery@intel.com>
Handle all date/time stamps uniformly, taking in account the host
endianness. Respect the local time zone and the '-Z' option for
all ipmitool commands. Unify the date and time formatting.
Add correct handling of IPMI timestamps 'since system startup'
and for 'unspecified' timestamps.
Partially resolvesipmitool/ipmitool#23
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Remove all direct comparisons to 'NULL' for pointers.
Replace them with boolean-like 'if (ptr)' and 'if (!ptr)'.
This makes conditions shorter and easier to read.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Make code better readable by replacing `if (rsp->ccode > 0)`
and 'if (rsp->ccode != 0)' with just `if (rsp->ccode)` as
rsp->ccode is anyway an unsigned byte and can't be negative.
Also replace 'if (rsp->ccode == 0)' with 'if (!rsp->ccode)'.
All these changes make lines shorter and easier to read as
a non-zero ccode is an indication of some failure, and so !ccode
naturally reads as 'no error'.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Add ARRAY_SIZE() macro.
Use the new macro in all places where array size is calculated by
means of sizeof(array)/sizeof(array[0]).
Fix minor bugs and warnings in the affected code.
Signed-off-by: Alexander Amelkin <alexander@amelkin.msk.ru>
Added an option -Z to display all dates in UTC.
Resolvesipmitool/ipmitool#19
Change-Id: Iac3a61190eefde12d95c892af26072ec01f60474
Signed-off-by: Nagaraju Goruganti <ngorugan@in.ibm.com>
Signed-off-by: Nagaraju Goruganti <ngorugan@in.ibm.com>
A segmentation fault was trigged by executing 'ipmitool fru internaluse 1 info'.
A memset() was attempted on the address of a pointer, not on the pointer itself.
The erroneous memset() is removed with this commit because it duplicates
the memset() in line 4072.
Resolvesipmitool/ipmitool#9
Signed-off-by: Kylix Lo <kylix0713@gmail.com>
The get_fru_area_str() function is used to decode FRU area
fields into text. Areas may be encoded as text, binary,
BCDplus or 6-bit ASCII. Decoding of 6-bit ASCII and BCDplus
was broken. There was an error in the formulas used to
calculate the resulting string length, plus the decoding
formulas for BCDplus was wrong.
For BCDplus the resulting length was considered equal
the encoded data length, while in fact it's twice as big.
Only one character instead of two was being extracted from
a single input byte while two nibbles must have been taken
into account.
For 6-bit ASCII rounding of 3 to 4 bytes conversion was done
improperly adding 2 to the original length instead of the
result of multiplication.
PICMG 3.1 R2.0 introduces new a new Link Class field in the FRU
Link Descriptors which is the upper 4 bits of the Link Type field.
This new Link Class field specifies SERDES lanes with 10.3125Gbd
signalling rate.
It also introduces the new Base-KX and Base-KX4 types which are the
new IEEE replacements for the PICMG 3.0 Base-BX and Base-BX4 types.
This patch decodes these new types and fields and will print out
proper descriptions for each one based on PICMG 3.1 R2.0
Targets as a problem with editing FRUs (like ipmitool ....
fru edit 0 field b 0 "blahblah") where the header (multirecord area offset) is
not correctly updated.
It is supposed to modify the header offset to muti-record area if any of
the three previous areas has been edited.
Remark: this has to occur before the new header crc is calculated.
Thats the reson the modification is not close to the actual movement of the
data. Maybe it would be nicer to change the order in the code here. But
I do not want to add undesired behaviour, thus keeping a clear and small
patch.
Editing a fru without resizing it caused the checksum being incorrect and not
being updated. This fix changes this, so the checksum is now being correctly
calculated and written to the right place.
