linux-kernel - core dump files do not include all CPU registers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <54917A5B.1050909@univention.de>
Date:	Wed, 17 Dec 2014 13:43:07 +0100
From:	Philipp Hahn <hahn@...vention.de>
To:	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
CC:	Frediano Ziglio <freddy77@...il.com>,
	Ian Campbell <Ian.Campbell@...rix.com>,
	Xen-devel@...ts.xen.org, Ian Jackson <Ian.Jackson@...citrix.com>
Subject: core dump files do not include all CPU registers?

Hello Linux folk,

while investigating some strange process crashes (SIGSEGV) we noticed
that the core files generated by the Linux kernel (3.10-amd64) do not
include all CPU registers; here namely the SSE2 (FPREGSET?) related
registers:

# eu-readelf --notes core
...
  CORE                 336  PRSTATUS
    info.si_signo: 11, info.si_code: 0, info.si_errno: 0, cursig: 11
    sigpend: <>
    sighold: <>
    pid: 6918, ppid: 18764, pgrp: 6918, sid: 18764
    utime: 1.116000, stime: 0.004000, cutime: 0.000000, cstime: 0.000000
    orig_rax: -1, fpvalid: 0
    r15:                       0  r14:                       0
    r13:         140734211556208  r12:                 4195248
    rbp:      0x0000000000000000  rbx:                       0
    r11:         140504440818576  r10:                       0
    r9:          140504444297440  r8:          140504444220160
    rax:                   80000  rcx:                       0
    rdx:                  100000  rsi:         140734211556216
    rdi:                       1  rip:      0x00000000004004e7
    rflags:   0x0000000000010246  rsp:      0x00007fff3cb00298
    fs.base:   0x00007fc9bd9df700  gs.base:   0x0000000000000000
    cs: 0x0033  ss: 0x002b  ds: 0x0000  es: 0x0000  fs: 0x0000  gs: 0x0000
...

In contrast to that "gdb generate-core-file" contains an additional note:
# eu-readelf --notes core.7335
...
  CORE                 512  FPREGSET
    xmm0:  0x00000000000000000000000000000000
    xmm1:  0x2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f2f
    xmm2:  0x00000000000000000000000000000000
    xmm3:  0x00000000000000000000ff0000000000
    xmm4:  0x00000000000000000000000000000000
    xmm5:  0x00000000000000000000000000000000
    xmm6:  0x00000000000000000000000000000000
    xmm7:  0x00000000000000000000000000000000
    xmm8:  0x00000000000000000000000000000000
    xmm9:  0x00000000000000000000000000000000
    xmm10: 0x00000000000000000000000000000000
    xmm11: 0x00000000000000000000000000000000
    xmm12: 0x00000000000000000000000000000000
    xmm13: 0x00000000000000000000000000000000
    xmm14: 0x00000000000000000000000000000000
    xmm15: 0x00000000000000000000000000000000
    st0: 0x00000000000000000000  st1: 0x00000000000000000000
    st2: 0x00000000000000000000  st3: 0x00000000000000000000
    st4: 0x00000000000000000000  st5: 0x00000000000000000000
    st6: 0x00000000000000000000  st7: 0x00000000000000000000
    mxcsr:   0x0000000000001f80
    fcw: 0x037f  fsw: 0x0000
...

Is there some way to include all CPU registers into the core dump, as
the current information is not enough to diagnose the cause of some
strange crashes, which might be related to the use of SSE2 with Xen.

Currently we're using this:
	kernel.core_pattern = /var/tmp/core/core-%e-%p-%t
	kernel.core_uses_pid = 1
	fs.suid_dumpable = 2

Would a "pipe" core-handler be able to access the still existing process
and create a more complete dump?


On 17.12.2014 10:14, Frediano Ziglio wrote:
> 2014-12-16 16:44 GMT+00:00 Frediano Ziglio <freddy77@...il.com>:
>> 2014-12-16 16:23 GMT+00:00 Ian Campbell <Ian.Campbell@...rix.com>:
...
>> First we (I'll try when I reach home) can check if memset in glibc (or
>> the version called from talloc_zero) can use SSE. A possible dmesg
>> output and /proc/cpuinfo content could help too but I think SSE are
>> now quite common.
> 
> I have access to some core dumps. glibc memset is using SSE,
> specifically xmm0 register.
> 
> Unfortunately is seems that core dumps contains only standard
> registers, so all register appears zeroed. If you try with a newer gdb
> version is shows that registers are not available.

Thank you in advance.
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/