linux-kernel - Re: 4KSTACKS + DEBUG

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]

Message-ID: <46D5FAE5.3020401@redhat.com>
Date:	Wed, 29 Aug 2007 18:01:57 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Jesper Juhl <jesper.juhl@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful

Jesper Juhl wrote:

>> Any suggestions for ways around this?  The warning is somewhat helpful,
>> and I guess the obvious option is to lighten up the dump_stack path, but
>> it's still effectively reducing precious available stack space by some
>> amount.
>>
> A first step could be to allocate those two char arrays with kmalloc()
> instead of on the stack, but then I guess that dump_stack() gets
> called from places where we may not really want to be calling
> kmalloc(). I guess we could allocate the buffers earlier (like at boot
> time) and store pointers somewhere where dump stack can get to them
> later when it needs them.

Yep, I thought about something like that... and I assume you'd need a
bit of locking around them too.

>> With CONFIG_DEBUG_STACK_USAGE, we could print at oops time: "oh, and by
>> the way, you blew your stack" if there is no zeroed stack space left, as
>> a post-mortem.  Even without that option, I think we could still check
>> whether the *current* %esp at oops time has gone too far?  But if we
>> blew the stack, returned, and *then* oops, I think it'd be hard to know
>> without the DEBUG_STACK_USAGE option that we ran out of room.
>>
> 
> We could also simply have it warn at a higher limit, like 1024 bytes
> instead of 512. But I guess then we would get too many false positives
> and make it less useful.

Yes, but if you happen to warn deeper anyway, just because you got
"lucky" with IRQ timing, you'll still explode.  Regardless of where the
threshold is, there's still a risk of starting the warning deeper than
that.  Whatever stack the warning takes effectively reduces the useable
stack size.

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