linux-kernel - Re: x86: 4kstacks default

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 for Android: free password hash cracker in your pocket

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

Message-ID: <480EF9DE.6000702@aitel.hist.no>
Date:	Wed, 23 Apr 2008 10:57:02 +0200
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	"Alexander E. Patrakov" <patrakov@...il.com>
CC:	Adrian Bunk <bunk@...nel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Eric Sandeen <sandeen@...deen.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Shawn Bohrer <shawn.bohrer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: x86: 4kstacks default

Alexander E. Patrakov wrote:
> Adrian Bunk wrote:
>> On Sun, Apr 20, 2008 at 08:41:27AM -0700, Arjan van de Ven wrote:
>>> ...
>>> yes. Adrian is waay off in the weeds on this one. Nobody but him is 
>>> suggesting to remove
>>> 8Kb stacks. I think everyone else agrees that having both options is 
>>> valuable; and there
>>> are better ways to find+fix stack bloat than removing this config 
>>> option.
>>
>> I'm not arguing for removing the option immediately, but long-term we 
>> shouldn't need it.
>>
>> This comes from my experience of removing obsolete drivers for 
>> hardware for which also a more recent driver exists:
>> As long as there is some workaround (e.g. using an older driver or
>> 8k stacks) the workaround will be used instead of the getting proper 
>> bug reports and fixes.
>>
>> As far as I know all problems that are known with 4k stacks are some 
>> nested things with XFS in the trace.
>
> This "as far as I know" is a problem itself. Is it possible to 
> implement (e.g., using some form of memory protection in hardware, but 
> I am not an expert here) an option with 8k stacks that, however, spams 
> the log if the actual usage goes above 4k, and have this as a default 
> for some time? If 4k stacks are the goal that is almost achieved, then 
> this debugging option should have zero impact on performance.
Shouldn't be hard. Use the 8k stack, and have the system mark the second 
page as "not present"
If it ever gets used you get a page fault. The page fault handler then 
have to mark the page
present before returning, as well as queue up some spam (the call chain 
perhaps) for the log.

A less intrusive way is to use 8k stacks as-is, but put a signature in 
the second page.
When the process quits, examine the second stack page to see if the 
signature
got overwritten. This approach will only show that a problem exists, it 
won't
pinpoint exactly what does it.

Helge Hafting

--
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/