Dear Maintainer,

   * What led up to the situation?

Ran a program linked against libfreeipmi2, for example bmc-config.

   * What was the outcome of this action?

Segfault:

[  304.932148] traps: bmc-config[6848] general protection ip:7fa773b714d8 sp:7ffffbda9070 error:0 in libfreeipmi.so.12.0.3[7fa773a13000+29d000]

   * What outcome did you expect instead?

No segfault?

The very very strange part of the bug is that this happens the first time libfreeipmi12 is used after a system boot, not subsequent times.

This is on 3.16-0.bpo.2-amd64, as the Dom0 for xen-4.1.  The hardware is a Dell Poweredge 840.

Ok, it's not exactly how I described it,

bmc-config (and some other commands) will crash *until* ipmi-sensors is
run, at which point it will start working.

Until the next reboot.

The bug only happens when running under xen, not on the bare metal.

So I guess it's a xen bug really.

thanks for digging into it... not sure if I should do anything about it,
but let's at least ask upstream

Dear Albert,

User reported some kernel trap hit upon initial boot in Xen instances,
see more detail :

Package: libfreeipmi12
Version: 1.1.5-3
http://bugs.debian.org/770472

Is that something familiar/resolvable at freeipmi level?

Cheers!

I imagine the bug is somewhere in xen's memory mapped I/O area if it's
happening the first time after boot.

Since I'm just using the normal in() and out() calls, not sure there's
much I can do.  If there is a way to massage freeipmi to not trigger the
bug we could work around it, but I have no idea how one might massage
it.
-- 
Albert Chu
chu11@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory

I'm pretty sure this is  a Xen bug -- another datapoint is that I have
another machine with the same setup where the Dom0 has spontaneously
rebooted 4 times - the problem "went away" when I tried ipmi-sensors on
it.   I imagine the reboots were caused by the kernel hitting the same trap.

I'll reassign to Xen and do more testing Monday.
























\

Hi,

I'm closing this bug: as you found, the crash only happened under Xen,
and upstream agreed it is outside freeipmi, which only uses plain in/out
port I/O after iopl().

The likely cause is the kernel bug fixed as CVE-2016-3157 / XSA-171
(IOPL not properly context-switched on 64-bit PV Xen guests), fixed in
Debian in June 2016 (DLA-516-1, DSA-3607-1).

If you can still reproduce it with a current kernel and freeipmi, please
reopen.

Regards,
Fabio