| commit | 3901c0eb75332aaa179948d230c0f71aa56dca02 | [log] [tgz] |
|---|---|---|
| author | Vasant Hegde <hegdevasant@linux.vnet.ibm.com> | Mon Oct 14 22:34:41 2019 +0530 |
| committer | Vasant Hegde <hegdevasant@linux.vnet.ibm.com> | Thu Jun 04 20:57:15 2020 +0530 |
| tree | 440725fb409adc151f2b0229237738f5e22f5311 | |
| parent | d92ab4d28b588d0ec357ebcd5de24627c38a93ea [diff] |
core/ipmi: Fix use-after-free
[ Upstream commit d75e82dbfbb9443efeb3f9a5921ac23605aab469 ]
Commit f01cd77 introduced backend poller() for ipmi message. But in some
corner cases its possible that we endup calling poller() after freeing
ipmi message.
Thread 1 :
ipmi_queue_msg_sync()
Waiting for ipmi sync message to complete
Thread 2 :
bt_poll() -> ipmi_cmd_done() -> callback handler -> free message
Oliver hit this issue during fast-reboot test with skiboot DEBUG build.
In debug build we poision the memory after free. That helped us to catch
this issue.
[ 460.295570781,3] ***********************************************
[ 460.295773157,3] Fatal MCE at 0000000030035cb4 .ipmi_queue_msg_sync+0x110 MSR 9000000000201002
[ 460.295887496,3] CFAR : 0000000030035ce8 MSR : 9000000000000000
[ 460.295956419,3] SRR0 : 0000000030035cb4 SRR1 : 9000000000201002
[ 460.296035015,3] HSRR0: 0000000030012624 HSRR1: 9000000002803002
[ 460.296102413,3] DSISR: 00000008 DAR : 99999999999999d1
[ 460.296169710,3] LR : 0000000030035ce4 CTR : 0000000030002880
[ 460.296248482,3] CR : 28002422 XER : 20040000
[ 460.296336621,3] GPR00: 0000000030035ce4 GPR16: 00000000301d36d8
[ 460.296415449,3] GPR01: 0000000031c133d0 GPR17: 00000000300f5cd8
[ 460.296482811,3] GPR02: 0000000030142700 GPR18: 0000000030407ff0
[ 460.296550265,3] GPR03: 0000000000000100 GPR19: 0000000000000000
[ 460.296629041,3] GPR04: 0000000028002424 GPR20: 0000000000000000
[ 460.296696369,3] GPR05: 0000000020040000 GPR21: 0000000030121d73
[ 460.296820977,3] GPR06: c000001fffffd480 GPR22: 0000000030121dd2
[ 460.296888226,3] GPR07: c000001fffffd480 GPR23: 0000000030613400
[ 460.296978218,3] GPR08: 0000000000000001 GPR24: 0000000000000001
[ 460.297056871,3] GPR09: 9999999999999999 GPR25: 0000000031c13960
[ 460.297124647,3] GPR10: 0000000000000000 GPR26: 0000000000000004
[ 460.297203811,3] GPR11: 0000000000000000 GPR27: 0000000000000003
[ 460.297271250,3] GPR12: 0000000028002424 GPR28: 0000000030613400
[ 460.297339026,3] GPR13: 0000000031c10000 GPR29: 0000000030406b50
[ 460.297417605,3] GPR14: 00000000300f58f8 GPR30: 0000000030406b40
[ 460.297485176,3] GPR15: 00000000300f58d8 GPR31: 00000000309249c8
Reported-by: Oliver O'Halloran <oohall@gmail.com>
Fixes: f01cd77 (ipmi: ensure forward progress on ipmi_queue_msg_sync())
Cc: skiboot-stable@lists.ozlabs.org # v6.3+
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
Firmware for OpenPower systems.
Source: https://github.com/open-power/skiboot
Mailing list: skiboot@lists.ozlabs.org
Info/subscribe: https://lists.ozlabs.org/listinfo/skiboot
Archives: https://lists.ozlabs.org/pipermail/skiboot/
Patchwork: http://patchwork.ozlabs.org/project/skiboot/list/
OPAL firmware (OpenPower Abstraction Layer) comes in several parts.
A simplified flow of what happens when the power button is pressed is:
Here, the OPAL image is three parts:
They may be all part of one payload or three separate images (depending on platform).
The bootloader will kexec a host kernel (probably linux). The host OS can make OPAL calls. The OPAL API is documented in doc/opal-api/ (there are missing parts, patches are welcome!)
See doc/overview.rst for a more in depth overview of skiboot.
Any host OS can build and test skiboot provided it has a C cross compiler for big endian powerpc64. All good Linux distributions (and several bad ones) provide a packaged compiler that can be installed through the usual package management tools.
To build on Ubuntu:
apt-get install gcc-powerpc64le-linux-gnu gcc valgrind \ expect libssl-dev device-tree-compiler make \ xz-utils CROSS=powerpc64le-linux-gnu- make -j`nproc`
To build on Fedora:
dnf install gcc-powerpc64le-linux-gnu binutils-powerpc64-linux-gnu gcc make \
diffutils findutils expect valgrind-devel dtc openssl-devel xz
CROSS=powerpc64le-linux-gnu- make -j`nproc`
(The little-endian powerpc64le compilers in Ubuntu and Fedora are actually bi-endian and can compile skiboot even though it's big-endian. We recommend installing a little-endian toolchain if you plan on building other projects.)
On any POWER system with a bi-endian system compiler:
CROSS="" make -j`nproc`
Alternatively, pre-built cross compilers for x86 systems can be downloaded from here: https://www.kernel.org/pub/tools/crosstool/ When using these compilers add /opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/ to your PATH. Once this is done skiboot can be compiler by just running make
Skiboot comes with a set of unit tests that can be run on your desktop. They can can be run with:
make check
To test in a simulator, install the IBM POWER8 Functional Simulator from: http://www-304.ibm.com/support/customercare/sas/f/pwrfs/home.html Also see external/mambo/README.md
Qemu as of version 2.8 implements the ‘powernv’ machine model and is sufficient to run skiboot:
qemu-system-ppc64 -M powernv -m 3G -nographic -L /path/to/skiboot/
To run a boot-to-bootloader test you need a Linux kernel image ‘zImage.epapr’. Build one using the opal_defconfig config for op-build. See https://github.com/open-power/op-build/ on how to build, or download one from https://openpower.xyz/job/openpower/job/openpower-op-build/.
Drop zImage.epapr in the skiboot directory and the skiboot test suite will automatically pick it up. You can also run a combined skiboot and Linux test in Qemu (version 3.0+):
qemu-system-ppc64 -M powernv -m 3G -nographic -kernel zImage.epapr -L /path/to/skiboot/
See opal-ci/README for further testing instructions.
To test on real hardware, you will need to understand how to flash new skiboot onto your system. This will vary from platform to platform.
You may want to start with external/boot-tests/boot_test.sh as it can (provided the correct usernames/passwords) automatically flash a new skiboot onto ASTBMC based OpenPower machines.
All patches should be sent to the mailing list with linux-kernel style ‘Signed-Off-By’. The following git commands are your friends:
git commit -s git format-patch
You probably want to read the linux https://kernel.org/doc/html/latest/process/submitting-patches.html as much of it applies to skiboot.
The Skiboot build process produces a bunch of different outputs. This is what they are, and where you should use them:
skiboot.elf: The output of the linker. Don't flash to a system, but useful when debugging
skiboot.lid: The raw binary object, named .lid because IBM. Flash this on really old P8 systems, the POWER Functional Simulator (mambo), or FSP systems
skiboot.lid.stb: Lid wrapped with secure boot header. Use on FSP systems
skiboot.lid.xz: Compressed raw binary. Use this on a OpenPower P8
skiboot.lid.xz.stb: Compressed raw binary wrapped with a secure boot header. Use this on OpenPower P9 systems
See LICENSE