selinux and thread local storage

selinux and thread local storage

[mm19827]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2545 bytes --]

Hi all,

I am trying to figure out something about Red Hat Bugzilla – Bug 1195074,
where nvidia libGL.so.304.125 hangs in an endless loop when loaded by
gnome-shell 3.14.

Sequence is: gnome-shell loads libGL.so which for some reason calls
is_selinux_enabled in libselinux.so at library load time, which runs into a
spinlock within init_thread_destructor when accessing the thread-local
variable destructor_initialized.

gdb print of destructor_initialized reports:
The inferior has not yet allocated storage for thread-local variables in the
shared library `/lib64/libselinux.so.1'

gdb backtrace is:

#0  0x0000003f12412495 in tls_get_addr_tail (ti=0x3509221f58,
dtv=0x7ffff7f83390, the_map=0x7ffff7f9c000)
    at dl-tls.c:751
#1  0x00003ðÀÌÔÀäÀÁ…˜Ǿ¥¸•ÑÁɽ…ÑÑɍ½¹}É…Ü€ ¤…ЁÁɽ…ÑÑȹŒèÜÌ(ŒÈ€€ÁàÀÀÀÀÀÀÌÔÀäÀÁ…˜Ǿ¥¸•ÑÁɽ…ÑÑɍ½¹}É…Ü(¡½¹Ñ•áÐõ½¹Ñ•áÑ\x01•¹ÑÉäôÁàÝ™™™™™™™å˜À°Á¥õÁ¥‘\x01•¹ÑÉäôÀ°)…ÑÑÈõ…ÑÑÉ\x01•¹ÑÉäôÁàÌÔÀäÀÄå”݈€‰ÕÉÉ•¹Ðˆ¤…ЁÁɽ…ÑÑȹŒèÄÈÄ(ŒÌ€€ÁàÀÀÀÀÀÀÌÔÀäÀÁˆÈÑ”¥¸•Ñ½¹}É…Ý}¥¹Ñ•É¹…°€¡Œõ\x01•¹ÑÉäôÁàÝ™™™™™™™å˜À¤…Ð)Áɽ…ÑÑȹŒèÌÌÐ(ŒÐ€€ÁàÀÀÀÀÀÀÌÔÀäÀÁ„ٍ”¥¸¥Í}Í•±¥¹Õá}•¹…‰±•‘}¥¹Ñ•É¹…°€ ¤…Ё•¹…‰±•¹ŒèÈØ(ŒÔ€€ÁàÀÀÀÀÀÀÌÔÁÁ„ÕŒÀ؁¥¸€€ ¤…Ѐ½±¥ˆØн±¥‰\x1d0¹Í¼¸Ä(ŒØ€€ÁàÀÀÀÀÀÀÌÔÁÀàь݈¥¸€€ ¤…Ѐ½±¥ˆØн±¥‰\x1d0¹Í¼¸Ä(ŒÜ€€ÁàÀÀÀÀÀÀ͘ÄÈÐÁ™••¥¸…±±}¥¹¥Ð€¡°ôÁàÝ™™™˜Ý˜ääå„ఁ…ɝŒõ…ɝ\x01•¹ÑÉäôÈ°)…ɝØõ…ɝÙ\x01•¹ÑÉäôÁàÝ™™™™™™™‘ŒÄఁ•¹Øõ•¹Ù\x01•¹ÑÉäôÁàÝ™™™™™™™‘ŒÌÀ¤…Ё‘°µ¥¹¥Ð¹ŒèØÈ(Œà€€ÁàÀÀÀÀÀÀ͘ÄÈÐÄÀÀ͈¥¸}‘±}¥¹¥Ð€¡•¹Øôñ½ÁÑ¥µ¥é•½ÕÐø°…ɝØôñ½ÁÑ¥µ¥é•)½ÕÐø°…ɝŒôñ½ÁÑ¥µ¥é•½ÕÐø°°ôñ½ÁÑ¥µ¯×¦VB\x06÷WCâ’\x06\x17B\x06FÂÖ–æ—Bæ3£3@¢3’\x02\x03\aƒ\x03\x03\x03\x03\x03\x036c\x13#C\x13\x03\x036"\x06–â\x05öFÅö–æ—B\x02†Ö\x16–åöÖ\x17\x03Ó\aƒ6c\x13#c#3\x13C‚Â\x06\x17&v3Ó"À¦\x17&wcÓ\aƒvfffffffF3\x13‚Â\x06VçcÓ\aƒvfffffffF33\x02’\x06\x17B\x06FÂÖ–æ—Bæ3£\x13#@¢3\x13\x02\x03\aƒ\x03\x03\x03\x03\x03\x036c\x13#C\x03\x06C&\x12\x06–â\x05öFÅ÷7F\x17'E÷W6W"\x02‚’\x06\x17B\x02öÆ–#cBöÆBÖÆ–çW‚׃ƒbÓcBç6òã ¢3\x13\x12\x03\aƒ\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03"\x06–â\x02\x02‚¢3\x13"\x03\aƒ\x03\x03\x03\x03vfffffffFfFB\x06–â\x02\x02‚¢3\x132\x03\aƒ\x03\x03\x03\x03vfffffffFfc"\x06–â\x02\x02‚¢3\x13B\x03\aƒ\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x02\x06–â\x02\x02‚ ¥F†—2\x06ö67W'2\x06\x17B\x06Æ–'&\x17'’\x06Æö\x16B\aF–ÖRÂ\a6ò\x06&Vf÷&R\x06vWGF–ær\aFò\x06Ö\x16–â‚’à¤\x16FF—F–öæ\x16Â\x06æ÷FR\x06—2\aF†\x17B\x04’\x06†\x17fR\aF†—2\a\a&ö&ÆVÒ\av—F‚\x06væöÖR×6†VÆÂÂ\x06'WB\x06Ö\x16ç’\x06÷F†W ¦W†V7WF\x16&ÆW2\x02†–æ6ÇVF–ær\x06væöÖR×6W76–öâÂ\x06vdž–æfòÂ\x06vdžvV\x17'2’\x06Æö\x16@¦Æ–$tÂç6òã3\x03Bã\x13#R\x06\x16æB\a'Vâ\x06§W7B\x06f–æRà ¥F†—2\a\a&ö&ÆVÒ\x06—2\a6–Ö–Æ\x17"\aFò\aF†R\x06öæR\x06FW67&–&VB\x06–ইGG\x03¢òöÖ\x17&2æ–æfòó÷CÓ\x13C##S#c“s\x13\x03\x03\x03\x032g#Ó\x12gsÓ ¦\x16ÇF†÷Vv‚\x06–â\x06×’\x066\x176R\av†\x17B\aVæÆö6·2\aF†R\a7\x06–æÆö6²\x06—2\aFò\x06Fò\x04ÄEõ\x05$TÄô\x14B\x06f÷"\x06Æ–$tÂç6òऒ\x06FöâwB\aF†–æ²\x04ÄEõ\x05$TÄô\x14B\x06—2\a&V\x16ÆÇ’\x06\x1fÈ\x19ÛÛÙ\b\x1cÛÛ\x1d]\x1a[Û‹ˆ\x10[žH\x1cÝYÙÙ\Ý\x1a[ۜς•Ú\x18]\b^[XZÙ\È\x1a]\b\x19\x1aY™šXÝ[\x1d\b\x1a\x19\™H\x1a\È\x1d\x1a\x18]\b^[šY\x1aXH^[\x1aX‘Ó\vœÛËŒÌ
\vŒLH\x1a\È\x18Û^[ÜÙY\x02œÛÝ\˜ÙK\b\x18[™\b\x1d\x1a\x18]\b\x18[\x1cÛÈ^[^[ØY\x1cÈ\x1cÛÛYH^[\x1aX›šY\x1aXK]^[\x1cÈ\x1dÚ\x1aXÚ\b\x1cÛÝ[™\x1cÈ\x1cÝ\Ü\x19XÝ\v\b\x18]\x02˜ÛÝ[\x19\b\x1d\x1a\x1a\È\x1cÝYÙÙ\Ý\b\x1cÛÛYH\x1d^[\x1cÈ\x1a[š]\x1aX[\x1a^˜]\x1a[Ûˆ\x1c\x1c›Ø›\x19[H\x1dÚ\x1a[\x19H\x19\x1e[˜[ZXÈ^[^[ØY\x1a[™È^[Ù‚›\x1aXœÙ[\x1a[^\x0f

Re: selinux and thread local storage

[Stephen Smalley]

On 04/14/2015 02:45 PM, mm19827 wrote:
> Hi all,
> 
> I am trying to figure out something about Red Hat Bugzilla – Bug 1195074,
> where nvidia libGL.so.304.125 hangs in an endless loop when loaded by
> gnome-shell 3.14.
> 
> Sequence is: gnome-shell loads libGL.so which for some reason calls
> is_selinux_enabled in libselinux.so at library load time, which runs into a
> spinlock within init_thread_destructor when accessing the thread-local
> variable destructor_initialized.
> 
> gdb print of destructor_initialized reports:
> The inferior has not yet allocated storage for thread-local variables in the
> shared library `/lib64/libselinux.so.1'
> 
> gdb backtrace is:
> 
> #0  0x0000003f12412495 in tls_get_addr_tail (ti=0x3509221f58,
> dtv=0x7ffff7f83390, the_map=0x7ffff7f9c000)
>     at dl-tls.c:751

Perhaps we could address this simply by changing is_selinux_enabled() to
use a private or inlined version of getcon_raw() that does not try to
cache the result and therefore does not rely on tls?

Re: selinux and thread local storage

[Daniel J Walsh]

On 04/14/2015 03:57 PM, Stephen Smalley wrote:
> On 04/14/2015 02:45 PM, mm19827 wrote:
>> Hi all,
>>
>> I am trying to figure out something about Red Hat Bugzilla – Bug 1195074,
>> where nvidia libGL.so.304.125 hangs in an endless loop when loaded by
>> gnome-shell 3.14.
>>
>> Sequence is: gnome-shell loads libGL.so which for some reason calls
>> is_selinux_enabled in libselinux.so at library load time, which runs into a
>> spinlock within init_thread_destructor when accessing the thread-local
>> variable destructor_initialized.
>>
>> gdb print of destructor_initialized reports:
>> The inferior has not yet allocated storage for thread-local variables in the
>> shared library `/lib64/libselinux.so.1'
>>
>> gdb backtrace is:
>>
>> #0  0x0000003f12412495 in tls_get_addr_tail (ti=0x3509221f58,
>> dtv=0x7ffff7f83390, the_map=0x7ffff7f9c000)
>>     at dl-tls.c:751
> Perhaps we could address this simply by changing is_selinux_enabled() to
> use a private or inlined version of getcon_raw() that does not try to
> cache the result and therefore does not rely on tls?
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
I would be fine with that.

Re: selinux and thread local storage

[mm19827]

Reposting with correct backtrace (hopefully)

On 04/14/2015 08:45 PM, mm19827 wrote:
> Hi all,
>
> I am trying to figure out something about Red Hat Bugzilla – Bug 1195074,
> where nvidia libGL.so.304.125 hangs in an endless loop when loaded by
> gnome-shell 3.14.
>
> Sequence is: gnome-shell loads libGL.so which for some reason calls
> is_selinux_enabled in libselinux.so at library load time, which runs into a
> spinlock within init_thread_destructor when accessing the thread-local
> variable destructor_initialized.
>
> gdb print of destructor_initialized reports:
> The inferior has not yet allocated storage for thread-local variables in the
> shared library `/lib64/libselinux.so.1'
>
> gdb backtrace is:
>
#0  0x0000003f12412495 in tls_get_addr_tail (ti=0x3509221f58, 
dtv=0x7ffff7f83390, the_map=0x7ffff7f9c000) at dl-tls.c:751
#1  0x000000350900af63 in getprocattrcon_raw () at procattr.c:73
#2  0x000000350900af63 in getprocattrcon_raw 
(context=context@entry=0x7fffffffd9f0, pid=pid@entry=0, 
attr=attr@entry=0x3509019e7b "current") at procattr.c:121
#3  0x000000350900b24e in getcon_raw_internal (c=c@entry=0x7fffffffd9f0) 
at procattr.c:334
#4  0x000000350900a6ce in is_selinux_enabled_internal () at enabled.c:26
#5  0x000000350d0a5c06 in  () at /lib64/libGL.so.1
#6  0x000000350d084c7b in  () at /lib64/libGL.so.1
#7  0x0000003f1240feed in call_init (l=0x7ffff7f999a8, 
argc=argc@entry=2, argv=argv@entry=0x7fffffffdc18, 
env=env@entry=0x7fffffffdc30) at dl-init.c:62
#8  0x0000003f1241003b in _dl_init (env=<optimized out>, argv=<optimized 
out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:34
#9  0x0000003f1241003b in _dl_init (main_map=0x3f12623148, argc=2, 
argv=0x7fffffffdc18, env=0x7fffffffdc30) at dl-init.c:124
#10 0x0000003f12400d2a in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#11 0x0000000000000002 in  ()
#12 0x00007fffffffdfdd in  ()
#13 0x00007fffffffdff2 in  ()
#14 0x0000000000000000 in  ()

This occurs at library load time, so before getting to main().
Additional note is that I have this problem with gnome-shell, but many 
other executables (including gnome-session, glxinfo, glxgears) load 
libGL.so.304.125 and run just fine.

This problem is similar to the one described in
http://marc.info/?t=142252697100003&r=1&w=2
although in my case what unlocks the spinlock is to do LD_PRELOAD for 
libGL.so.

What makes it difficult here is that nvidia libGL.so.304.125 is closed 
source, and that also loads some libnvidia-tls.so which sounds like 
being involved with tls (no response from nvidia yet), so not much 
really clear, but I posted this in case it may suggest anything between 
selinux and tls.

Re: selinux and thread local storage

[Stephen Smalley]

On 04/15/2015 01:25 PM, Daniel J Walsh wrote:
> 
> On 04/14/2015 03:57 PM, Stephen Smalley wrote:
>> On 04/14/2015 02:45 PM, mm19827 wrote:
>>> Hi all,
>>>
>>> I am trying to figure out something about Red Hat Bugzilla – Bug 1195074,
>>> where nvidia libGL.so.304.125 hangs in an endless loop when loaded by
>>> gnome-shell 3.14.
>>>
>>> Sequence is: gnome-shell loads libGL.so which for some reason calls
>>> is_selinux_enabled in libselinux.so at library load time, which runs into a
>>> spinlock within init_thread_destructor when accessing the thread-local
>>> variable destructor_initialized.
>>>
>>> gdb print of destructor_initialized reports:
>>> The inferior has not yet allocated storage for thread-local variables in the
>>> shared library `/lib64/libselinux.so.1'
>>>
>>> gdb backtrace is:
>>>
>>> #0  0x0000003f12412495 in tls_get_addr_tail (ti=0x3509221f58,
>>> dtv=0x7ffff7f83390, the_map=0x7ffff7f9c000)
>>>     at dl-tls.c:751
>> Perhaps we could address this simply by changing is_selinux_enabled() to
>> use a private or inlined version of getcon_raw() that does not try to
>> cache the result and therefore does not rely on tls?
>>
>>
> I would be fine with that.

Actually, could we just drop the test altogether of whether getcon()
returns "kernel", i.e. no-policy-loaded?  IIRC, this is a leftover of
Fedora Core 2 days, before we had support for SELinux runtime disable,
so that we could emulate SELinux disabled by just not loading a policy.
 But these days SELinux can be disabled either via SELINUX=disabled in
/etc/selinux/config or selinux=0 and either way selinuxfs is
unregistered and /sys/fs/selinux is unmounted, so we should not need
this test anymore AFAICS.