How to get value of gs:0xc with LTS note in coredump?

How to get value of gs:0xc with LTS note in coredump?

[慕冬亮]

Dear all,

I have a question about gs and TLS in core dump. When I read the
assembly code from one coredump, there is one memory dereference :
gs:[edx] or gs:0xc.

I googled gs register and found it points to Thread Local Storage.
However, gs is a selector to GDT and this structure is in the kernel.
And I could not obtain it in coredump.

Then I searched all the segments in core dump. I found a note entry
with type NT_386_TLS, length 0x30. Is gs:0xc in this note ? And gs:0xc
is the 12th element of this note entry?

--
My best regards to you.

     No System Is Safe!
     Dongliang Mu

Re: How to get value of gs:0xc with LTS note in coredump?

[Jan Kratochvil]

On Tue, 04 Oct 2016 02:59:45 +0200, 慕冬亮 wrote:
> I have a question about gs and TLS in core dump. When I read the
> assembly code from one coredump, there is one memory dereference :
> gs:[edx] or gs:0xc.
> 
> I googled gs register and found it points to Thread Local Storage.
> However, gs is a selector to GDT and this structure is in the kernel.
> And I could not obtain it in coredump.

%gs on i386 (and %fs on x86_64) points to pthread_self() which is
'struct pthread *' (if you have glibc debug info available) where at offset 0xc
is 'void *self' which is the pthread_self() pointer itself (%gs:0xc is faster
to access).


> Then I searched all the segments in core dump. I found a note entry
> with type NT_386_TLS, length 0x30. Is gs:0xc in this note ? And gs:0xc
> is the 12th element of this note entry?

Yes, pthread_self() is coincidentally also the value of %gsbase (%fsbase on
x86_64) but GDB cannot show that register, in a core file you can see it by
"eu-readelf -n" (from elfutils, "readelf -n" from binutils does not show it)
as:
  LINUX                 48  386_TLS
    index: 12, base: 0xf7778800, limit: 0x000fffff, flags: 0x00000051
                     ^^^^^^^^^^=pthread_self()


Jan

Re: How to get value of gs:0xc with LTS note in coredump?

[慕冬亮]

2016-10-03 21:20 GMT-04:00 Jan Kratochvil <jan.kratochvil@redhat.com>:
> On Tue, 04 Oct 2016 02:59:45 +0200, 慕冬亮 wrote:
>> I have a question about gs and TLS in core dump. When I read the
>> assembly code from one coredump, there is one memory dereference :
>> gs:[edx] or gs:0xc.
>>
>> I googled gs register and found it points to Thread Local Storage.
>> However, gs is a selector to GDT and this structure is in the kernel.
>> And I could not obtain it in coredump.
>
> %gs on i386 (and %fs on x86_64) points to pthread_self() which is
> 'struct pthread *' (if you have glibc debug info available) where at offset 0xc
> is 'void *self' which is the pthread_self() pointer itself (%gs:0xc is faster
> to access).
>
>
>> Then I searched all the segments in core dump. I found a note entry
>> with type NT_386_TLS, length 0x30. Is gs:0xc in this note ? And gs:0xc
>> is the 12th element of this note entry?
>
> Yes, pthread_self() is coincidentally also the value of %gsbase (%fsbase on
> x86_64) but GDB cannot show that register, in a core file you can see it by
> "eu-readelf -n" (from elfutils, "readelf -n" from binutils does not show it)
> as:
>   LINUX                 48  386_TLS
>     index: 12, base: 0xf7778800, limit: 0x000fffff, flags: 0x00000051
>                      ^^^^^^^^^^=pthread_self()
>

I need to analyze this note entry in my C code. How is it arranged by
kernel or gdb?
And what's the data structure for every item in this entry?

LINUX                 48  386_TLS
    index: 6, base: 0xb7fd57c0, limit: 0x000fffff, flags: 0x00000051
    index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
    index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028

The above is output from "eu-readelf -n  mycore".

--
My best regards to you.

     No System Is Safe!
     Dongliang Mu


>
> Jan

Re: How to get value of gs:0xc with LTS note in coredump?

[Jan Kratochvil]

On Tue, 04 Oct 2016 03:48:38 +0200, 慕冬亮 wrote:
> I need to analyze this note entry in my C code. How is it arranged by
> kernel or gdb?
> And what's the data structure for every item in this entry?
> 
> LINUX                 48  386_TLS
>     index: 6, base: 0xb7fd57c0, limit: 0x000fffff, flags: 0x00000051
>     index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
>     index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028

Do you really want to analyze _the_note_?  There is only useful the address
0xb7fd57c0.  You can analyze where the address points to, it should look like:

(gdb) p *(struct pthread *)0xb7fd57c0
$1 = {{header = {tcb = 0xb7fd57c0, dtv = 0xb7fd57c8, self = 0xb7fd57c0, multiple_threads = 0, sysinfo = 4160576768, stack_guard = 4193608960, pointer_guard = 1631022810, gscope_flag = 0, __glibc_reserved1 = 0, __private_tm = {0x0, 0x0, 0x0, 0x0}, __private_ss = 0x0}, __padding = {0xf7fd2800, 0xf7fd2d08, 0xf7fd2800, 0x0, 0xf7fd5d00 <__kernel_vsyscall>, 0xf9f56500, 0x61376eda, 0x0 <repeats 17 times>}}, list = {next = 0xf7fc4184 <__stack_user>, prev = 0xf7fc4184 <__stack_user>}, tid = 20170, pid = 20170, {robust_list = {__next = 0xf7fd2870}, robust_head = {list = 0xf7fd2870, futex_offset = -20, list_op_pending = 0x0}}, cleanup = 0x0, cleanup_jmp_buf = 0xffffcb44, cancelhandling = 0, flags = 0, specific_1stblock = {{seq = 0, data = 0x0} <repeats 32 times>}, specific = {0xf7fd288c, 0x0 <repeats 31 times>}, specific_used = false, report_events = false, user_stack = true, stopped_start = false, parent_cancelhandling = 0, lock = 0, setxid_futex = 0, cpuclock_offset = 2898183629324184, joinid = 0x0, result = 0x0, schedparam = {__sched_priority = 0}, schedpolicy = 0, start_routine = 0x0, arg = 0x0, eventbuf = { eventmask = {event_bits = {0, 0}}, eventnum = TD_ALL_EVENTS, eventdata = 0x0}, nextevent = 0x0, exc = {exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 0}, stackblock = 0x0, stackblock_size = 4294953904, guardsize = 0, reported_guardsize = 0, tpp = 0x0, res = {retrans = 0, retry = 0, options = 0, nscount = 0, nsaddr_list = {{sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = { s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}}, id = 0, dnsrch = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, defdname = '\000' <repeats 255 times>, pfcode = 0, ndots = 0, nsort = 0, ipv6_unavail = 0, unused = 0, sort_list = {{addr = { s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, { addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}}, qhook = 0x0, rhook = 0x0, res_h_errno = 0, _vcsock = 0, _flags = 0, _u = {pad = '\000' <repeats 51 times>, _ext = {nscount = 0, nsmap = {0, 0, 0}, nssocks = {0, 0, 0}, nscount6 = 0, nsinit = 0, nsaddrs = {0x0, 0x0, 0x0}, initstamp = 0}}}, end_padding = 0xf7fd2c84 ""} 

But most of the interesting information is usually in application TLS
variables which are _under_ this address:
$ readelf -s executable|grep TLS
    59: 00000000     4 TLS     GLOBAL DEFAULT   19 x
    70: 00000004     4 TLS     GLOBAL DEFAULT   19 y
That address 0 and 4 are shifted down from the pthread_self(), you can try to
compile some code.

 80484dd:       65 a1 f8 ff ff ff       mov    %gs:0xfffffff8,%eax  ; that is 'x' at -8


Jan

Re: How to get value of gs:0xc with LTS note in coredump?

[慕冬亮]

2016-10-04 2:57 GMT-04:00 Jan Kratochvil <jan.kratochvil@redhat.com>:
> On Tue, 04 Oct 2016 03:48:38 +0200, 慕冬亮 wrote:
>> I need to analyze this note entry in my C code. How is it arranged by
>> kernel or gdb?
>> And what's the data structure for every item in this entry?
>>
>> LINUX                 48  386_TLS
>>     index: 6, base: 0xb7fd57c0, limit: 0x000fffff, flags: 0x00000051
>>     index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
>>     index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
>
> Do you really want to analyze _the_note_?  There is only useful the address
> 0xb7fd57c0.  You can analyze where the address points to, it should look like:
>
> (gdb) p *(struct pthread *)0xb7fd57c0
> $1 = {{header = {tcb = 0xb7fd57c0, dtv = 0xb7fd57c8, self = 0xb7fd57c0, multiple_threads = 0, sysinfo = 4160576768, stack_guard = 4193608960, pointer_guard = 1631022810, gscope_flag = 0, __glibc_reserved1 = 0, __private_tm = {0x0, 0x0, 0x0, 0x0}, __private_ss = 0x0}, __padding = {0xf7fd2800, 0xf7fd2d08, 0xf7fd2800, 0x0, 0xf7fd5d00 <__kernel_vsyscall>, 0xf9f56500, 0x61376eda, 0x0 <repeats 17 times>}}, list = {next = 0xf7fc4184 <__stack_user>, prev = 0xf7fc4184 <__stack_user>}, tid = 20170, pid = 20170, {robust_list = {__next = 0xf7fd2870}, robust_head = {list = 0xf7fd2870, futex_offset = -20, list_op_pending = 0x0}}, cleanup = 0x0, cleanup_jmp_buf = 0xffffcb44, cancelhandling = 0, flags = 0, specific_1stblock = {{seq = 0, data = 0x0} <repeats 32 times>}, specific = {0xf7fd288c, 0x0 <repeats 31 times>}, specific_used = false, report_events = false, user_stack = true, stopped_start = false, parent_cancelhandling = 0, lock = 0, setxid_futex = 0, cpuclock_offset = 2898183629324184, joinid = 0x0, result = 0x0, schedparam = {__sched_priority = 0}, schedpolicy = 0, start_routine = 0x0, arg = 0x0, eventbuf = { eventmask = {event_bits = {0, 0}}, eventnum = TD_ALL_EVENTS, eventdata = 0x0}, nextevent = 0x0, exc = {exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 0}, stackblock = 0x0, stackblock_size = 4294953904, guardsize = 0, reported_guardsize = 0, tpp = 0x0, res = {retrans = 0, retry = 0, options = 0, nscount = 0, nsaddr_list = {{sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = { s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}}, id = 0, dnsrch = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, defdname = '\000' <repeats 255 times>, pfcode = 0, ndots = 0, nsort = 0, ipv6_unavail = 0, unused = 0, sort_list = {{addr = { s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, { addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}, {addr = {s_addr = 0}, mask = 0}}, qhook = 0x0, rhook = 0x0, res_h_errno = 0, _vcsock = 0, _flags = 0, _u = {pad = '\000' <repeats 51 times>, _ext = {nscount = 0, nsmap = {0, 0, 0}, nssocks = {0, 0, 0}, nscount6 = 0, nsinit = 0, nsaddrs = {0x0, 0x0, 0x0}, initstamp = 0}}}, end_padding = 0xf7fd2c84 ""}
>
> But most of the interesting information is usually in application TLS
> variables which are _under_ this address:
> $ readelf -s executable|grep TLS
>     59: 00000000     4 TLS     GLOBAL DEFAULT   19 x
>     70: 00000004     4 TLS     GLOBAL DEFAULT   19 y
> That address 0 and 4 are shifted down from the pthread_self(), you can try to
> compile some code.
>
>  80484dd:       65 a1 f8 ff ff ff       mov    %gs:0xfffffff8,%eax  ; that is 'x' at -8
>

There are three entries in this note. I am not sure there is only one
useful entry in 32bit linux. What's your opinion?

And I need a data structure to represent each entry. Is this data
structure in /usr/inclucde/elf.h like Elf32_Nhdr?

Each thread has a note NT_386_LTS, yes? I need to attach such a base
address to each thread.

--
My best regards to you.

     No System Is Safe!
     Dongliang Mu


>
> Jan