| commit | 6ad4dc0ff0a4ea5f4be986bb80cb16f764c3a460 | [log] [tgz] |
|---|---|---|
| author | Andrew Jeffery <andrew@aj.id.au> | Wed Apr 12 15:56:45 2023 +0930 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Thu Apr 13 22:48:30 2023 +0930 |
| tree | 12cc3a58a6106a6206522114088d24c4426f512c | |
| parent | 5646f23b55c0ce4143278ffca3a6c8c3193467a2 [diff] |
tests: platform: Fix TEST(GetStateSensorReadings, testBadDecodeResponse)
Fix up an off-by-one error in the test suite. I modified the test to
instead report more sensors than were present in the message buffer and
received the following from ASAN:
```
=================================================================
==297936==ERROR: AddressSanitizer: stack-buffer-overflow on address 0xffffc18300b9 at pc 0xffffa04cae2c bp 0xffffc182fe40 sp 0xffffc182fe58
READ of size 1 at 0xffffc18300b9 thread T0
#0 0xffffa04cae28 in pldm_msgbuf_extract_uint8 ../src/msgbuf/../msgbuf.h:129
#1 0xffffa04cae28 in decode_get_state_sensor_readings_resp ../src/platform.c:804
#2 0x2c0278 in GetStateSensorReadings_testBadDecodeResponse_Test::TestBody() ../tests/libpldm_platform_test.cpp:843
#3 0xffffa03ba0f8 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (/lib64/libgtest.so.1.12.1+0x4a0f8)
#4 0xffffa03a6680 in testing::Test::Run() (/lib64/libgtest.so.1.12.1+0x36680)
#5 0xffffa03a688c in testing::TestInfo::Run() (/lib64/libgtest.so.1.12.1+0x3688c)
#6 0xffffa03a6c30 in testing::TestSuite::Run() (/lib64/libgtest.so.1.12.1+0x36c30)
#7 0xffffa03b2dd0 in testing::internal::UnitTestImpl::RunAllTests() (/lib64/libgtest.so.1.12.1+0x42dd0)
#8 0xffffa03b1998 in testing::UnitTest::Run() (/lib64/libgtest.so.1.12.1+0x41998)
#9 0xffffa0400940 in main (/lib64/libgtest_main.so.1.12.1+0x940)
#10 0xffff9f80b584 in __libc_start_call_main (/lib64/libc.so.6+0x2b584)
#11 0xffff9f80b65c in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x2b65c)
#12 0x2b2a6c in _start (/mnt/host/andrew/src/openbmc/libpldm/build/tests/libpldm_platform_test+0x2b2a6c)
Address 0xffffc18300b9 is located in stack of thread T0 at offset 297 in frame
#0 0x2bfe90 in GetStateSensorReadings_testBadDecodeResponse_Test::TestBody() ../tests/libpldm_platform_test.cpp:811
This frame has 14 object(s):
[48, 49) 'retcompletion_code' (line 831)
[64, 65) 'retcomp_sensorCnt' (line 832)
[80, 84) 'rc' (line 819)
[96, 100) '<unknown>'
[112, 116) 'stateField' (line 827)
[128, 132) 'retstateField' (line 833)
[144, 148) '<unknown>'
[160, 168) '<unknown>'
[192, 200) '<unknown>'
[224, 232) '<unknown>'
[256, 264) '<unknown>'
[288, 297) 'responseMsg' (line 815) <== Memory access at offset 297 overflows this variable
[320, 336) 'gtest_ar' (line 822)
[352, 368) 'gtest_ar' (line 847)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../src/msgbuf/../msgbuf.h:129 in pldm_msgbuf_extract_uint8
Shadow bytes around the buggy address:
0x200ff8305fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8305fd0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
0x200ff8305fe0: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8305ff0: 00 00 f1 f1 f1 f1 f1 f1 01 f2 01 f2 04 f2 f8 f2
0x200ff8306000: 04 f2 04 f2 04 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2
=>0x200ff8306010: f2 f2 00 f2 f2 f2 00[01]f2 f2 f8 f8 f2 f2 00 00
0x200ff8306020: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8306030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8306040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8306050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x200ff8306060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==297936==ABORTING
```
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Change-Id: Ib63254bd345d28924aee47eb230bcbea0c88811a
This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:
Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.
Given a PLDM command "foo", the library will provide the following API: For the Requester function:
encode_foo_req() - encode a foo request decode_foo_resp() - decode a response to foo
For the Responder function:
decode_foo_req() - decode a foo request encode_foo_resp() - encode a response to foo
The library also provides API to pack and unpack PLDM headers.
Need meson and ninja. Alternatively, source an OpenBMC ARM/x86 SDK.
meson setup builddir && ninja -C builddir
The simplest way of running the tests is as described by the meson man page:
meson setup builddir && meson test -C builddir
This will support OEM or vendor-specific functions and semantic information. Following directory structure has to be used:
libpldm |---- include/libpldm | |---- oem/<oem_name>/libpldm | |----<oem based .h files> |---- src | |---- oem/<oem_name> | |----<oem based .c files> |---- tests | |---- oem/<oem_name> | |----<oem based test files>
<oem_name> - This folder must be created with the name of the OEM/vendor in lower case.
Header files & source files having the oem functionality for the libpldm library should be placed under the respective folder hierarchy as mentioned in the above figure. They must be adhering to the rules mentioned under the libpldm section above.
Once the above is done a meson option has to be created in libpldm/meson_options.txt with its mapped compiler flag to enable conditional compilation.
For consistency would recommend using "oem-<oem_name>".
The libpldm/meson.build and the corresponding source file(s) will need to incorporate the logic of adding its mapped compiler flag to allow conditional compilation of the code.
The pldm requester API's are present in src/requester folder and they are intended to provide API's to interact with the desired underlying transport layer to send/receive pldm messages.
NOTE : In the current state, the requester API's in the repository only works with specific transport mechanism & these are going to change in future & probably aren't appropriate to be writing code against.