Re: SIGSEGV in LuaJIT 2.1 VM

  • From: Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Fri, 18 Nov 2016 16:43:40 +0300

Tomas,

Quick googling wasn’t unfortunately very helpful.
Welcome to our world!

Please note, you are most probably not experiencing the issue with
reading/writing. You are experiencing an issue with __executing__ the code
that's right under your RIP (first instruction of the compiled trace).
Region mapping will show CODE attribute for it, but I believe it is not
that way at the moment of execution within the hardware.

Let's put aside the thread affinity approach, as it's more complex. You can
diagnose the issue quite rapidly with the unprotected mcode approach: in
'src/lj_mcode.h', find "LUAJIT_UNPROTECT_MCODE" symbol. It's a define,
that's not set by default. Set it unconditionally above the first usage,
re-compile and re-deploy. If it stops crashing, that's our bug.

Please read and understand carefully what this define means (right after
the first usage) and use it at your own risk. As a side note, it does not
affect stability, but brings a very-very potential vulnerability in your
service. Like, very-very potentinal. I think it's the best way to use this
approach for diagnostic purpose only and, if it helps, return here for more
solid solution (for example, the one proposed by Peter).

Hope that helps.

On Fri, Nov 18, 2016 at 4:21 PM, Tomas Kvasnicka <nzt4567@xxxxxxx> wrote:

Peter and Igor,

thanks a lot for your responses. I’ve checked the protection of 0x401bb410
and as I have more core dumps from identical issue I have also checked the
protection status of all other addresses that are the destination in the
mov instructions causing the SIGSEGV. It’s unfortunately just as Igor says
- they always have just "ALLOC LOAD HAS_CONTENTS” but never READONLY so the
destination addresses should be writable I believe. As the CPUs are all
x86_64 Intel E5s I guess it might be possible that I am actually facing the
bug Igor is talking about - which BTW doesn’t make me very happy :)

* use unprotected mcode;
* apply thread affinity for threads running LuaJIT;

Igor - could you please point me to some resources elaborating on how to
achieve these? Quick googling wasn’t unfortunately very helpful.

If Tomas has a semi-reproducible setup, I'd be interested to know
whether the following has any effect: (if for some reason the hardware
sees this as cross-modifying code rather than self-modifying code,
then some kind of serializing instruction is required for some
hardware models)
Peter - thanks a lot, appreciate the patch very much. It should not be a
problem to reproduce it - not that I would be able to do so on purpose, but
it happens at least once a day on at least one of our production servers.
I’ll build a new version, get it deployed and get back to you after the
weekend with (hopefully good) news.

Once again thank you very much for your responses, both of you. It has
been driving me crazy for the past few nights :)

Tomas

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 11-2016