linux-kernel - Re: /proc/<pid>/status & task struct locking

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-prev] [day] [month] [year] [list]

Date:	Fri, 15 Apr 2016 11:39:22 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Jones <davej@...emonkey.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: /proc/<pid>/status & task struct locking

On Fri, Apr 15, 2016 at 11:23 AM, Dave Jones <davej@...emonkey.org.uk> wrote:
>
> To put my mind at rest though, am I wrong about that absent task_lock() stuff ?

So the task shouldn't be going away, because we are using the
proc_single_file_operations, which use proc_single_show(), which in
turn do a

        task = get_pid_task(pid, PIDTYPE_PID);
        ...
        put_task_struct(task);

around it all.

So dereferencing the task pointer is all safe, and the only reason to
use task_lock() is if you end up doing something more complicated.

I'm not seeing anything wrong there. It does do the get_task_mm()
before touching mm fields, and the signal fields get protected by
lock_task_sighand().  The rest seems to just dereference the task
struct directly, and if those values fluctuate that's fine: you get
one or the other, no amount of locking will make /proc/pid/status give
"reliable" values in the big picture, since the user-space reader
won't have the lock anyway.

So it all looks fine to me, but I'm not saying I did some exhaustive check.

                  Linus