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>] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Dec 2017 13:54:56 +0100 (CET)
From:   Miroslav Benes <mbenes@...e.cz>
To:     luto@...nel.org, jpoimboe@...hat.com
cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org
Subject: stack traces and zombie tasks

Hi,

commit 1959a60182f4 ("x86/dumpstack: Pin the target stack when dumping 
it") slightly changed the behaviour of stack traces dumping for zombie 
tasks.

Before the commit (well, this is older SLE12 kernel, but that should not 
matter), if one called 'cat /proc/<zombie pid>/stack', they would get 
something like this

  [<ffffffff8105b877>] do_exit+0x6f7/0xa80
  [<ffffffff8105bc79>] do_group_exit+0x39/0xa0
  [<ffffffff8105bcf0>] __wake_up_parent+0x0/0x30
  [<ffffffff8152dd09>] system_call_fastpath+0x16/0x1b
  [<00007fd128f9c4f9>] 0x7fd128f9c4f9
  [<ffffffffffffffff>] 0xffffffffffffffff

After, one gets nothing. The trace is empty. try_get_task_stack() contains 
atomic_inc_not_zero() (CONFIG_THREAD_INFO_IN_TASK is now default on 
x86_64) and because stack_refcount is 0 for a zombie task, it returns 
NULL. Therefore, all save_stack_trace_*() functions return immediately.

I guess that no one has cared about it so far. There is a problem for 
live patching though. save_stack_trace_tsk_reliable() returns -EINVAL for 
the zombie task and its stack is deemed unreliable. It could block our 
transition for quite a long time.

We can skip those tasks in kernel/livepatch/ with a simple test we have in 
kGraft. Skip the task if (task->state == TASK_DEAD && task->on_cpu == 0). 
But you may want to change it generally, so better to ask first.

Regards,
Miroslav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ