linux-kernel - Re: [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation

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

Date:	Wed, 20 Jan 2016 08:51:38 +0530
From:	Siddhesh Poyarekar <siddhesh.poyarekar@...il.com>
To:	"Kirill A. Shutemov" <kirill@...temov.name>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>, Shaohua Li <shli@...com>,
	linux-mm@...ck.org, linux-kernel <linux-kernel@...r.kernel.org>,
	kernel-team@...com
Subject: Re: [PATCH] proc: revert /proc/<pid>/maps [stack:TID] annotation

On 20 January 2016 at 05:00, Kirill A. Shutemov <kirill@...temov.name> wrote:
> I doubt it can be very useful as it's unreliable: if two stacks are
> allocated end-to-end (which is not good idea, but still) it can only
> report [stack:XXX] for the first one as they are merged into one VMA.
> Any other anon VMA merged with the stack will be also claimed as stack,
> which is not always correct.

It is quite uncommon because you will always have an intervening guard
page that separates the two stack vmas.  To have the vmas merge, you
will have to disable guard pages which is an even worse idea.

A more relevant argument about its unreliability is context changes
due to makecontext/setcontext, which could momentarily show the heap
or some other arbitrary vma as a stack.

Siddhesh
-- 
http://siddhesh.in