Bug #9249: Ruby incorrectly inspects opaque libc jmp_buf for pointers to heap during GC.

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: 2.0.0-p353

[[e-mail] (Carlos O'Donell)]

The garbage collector in Ruby inspects the opaque libc jmp_buf (as used by setjmp and longjmp) for pointers to heap during GC

This imposes an ABI requirement on glibc to keep the jmp_buf visible to Ruby. Ruby's inspection of the opaque jmp_buf goes against POSIX.

Recently the ARM glibc maintainer tried to encrypt more jmp_buf pointers (as part of the pointer mangling security work) on 32-bit ARM but Fedora Rawhide testing found that this broke Ruby's GC.

Ruby must not inspect jmp_buf. The buffer layout, size, and contents are subject to arbitrary change by the implementation.

It could be argued that if the jmp_buf were placed on the stack, that a stack scan would run into the same problems, but it doesn't from the standards perspective.

The point is that the entire jmp_buf could eventually be encrypted and the ruby gc scheme should continue to work.

If ruby needs anything from glibc we need to coordinate and make sure both communities stay on the same page.

This problem isn't unique to ruby, but it has recently caused us problems.

I fully understand that as a language implementation that ruby might need to do some things that are slightly outside of the standard. That's fine, but we need to talk them through and agree on them.

In the meantime we are likely going to encrypt less of the jmp_buf on ARM to keep ruby working.

While this bug is filed against 2.0.0-p353 the same code exists in trunk.

Ruby mailing list discussion:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/59052

glibc mailing list discussion:
https://sourceware.org/ml/libc-alpha/2013-12/msg00340.html

[akr (Akira Tanaka)]

Is there an alternative function to dump registers for conservative GC?

I think Ruby (and other programs with conservative GC) can use such function if available.

Is there an alternative function to dump registers for conservative GC?

On GCC, I think you can force registers to be saved to the stack before calling by marking a function with attribute((returns_twice))

[mame (Yusuke Endoh)]

In principle, Boehm GC tries to use, in turn, getcontext, __builtin_unwind_init, and then setjmp.
The actual code has some assembly hacks to work around some platform bugs (?), though..

https://github.com/ivmai/bdwgc/blob/master/mach_dep.c#L213

--
Yusuke Endoh [e-mail]

[vo.x (Vit Ondruch)]

Interestingly enough, I can't build Ruby 2.0.0 [1] but Ruby 2.1.0 [2] passes on the same configuration just fine. What was changed?

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6309509
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=6308777

[akr (Akira Tanaka)]

2013/12/15 mame (Yusuke Endoh) [e-mail]:

Issue #9249 has been updated by mame (Yusuke Endoh).

In principle, Boehm GC tries to use, in turn, getcontext, __builtin_unwind_init, and then setjmp.

I think they are not supposed to be used for conservative GC.
So they may encrypt pointers eventually.

Tanaka Akira

[mame (Yusuke Endoh)]

akr (Akira Tanaka) wrote:

I think they are not supposed to be used for conservative GC.
So they may encrypt pointers eventually.

Of course. I think there is no "supposed" and portable way to get the content of the registers.

--
Yusuke Endoh [e-mail]

[vo.x (Vit Ondruch)]

Was this resolved somehow? Testing this on Fedora 20, where the FP mangling was enabled [1], Ruby 2.0.0 fails:

https://kojipkgs.fedoraproject.org//work/tasks/1623/8321623/build.log

while the Ruby 2.2.0-preview2 passes:

https://kojipkgs.fedoraproject.org//work/tasks/1676/8321676/build.log

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1159326

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed
• Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)