[ruby-core:59110] [ruby-trunk - Bug #9249][Open] Ruby incorrectly inspects opaque libc jmp_buf for pointers to heap during GC.

Issue #9249 has been reported by [e-mail] (Carlos O'Donell).

----------------------------------------
Bug #9249: Ruby incorrectly inspects opaque libc jmp_buf for pointers to heap during GC.
https://bugs.ruby-lang.org/issues/9249

Author: [e-mail] (Carlos O'Donell)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: 2.0.0-p353
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


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


-- 
http://bugs.ruby-lang.org/