linux-kernel - Re: [PATCH] Reduce __print_symbol/sprint

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:	Fri, 21 Sep 2007 17:02:29 +0100
From:	Paulo Marques <pmarques@...popie.com>
To:	gilboad@...il.com
CC:	linux-kernel@...r.kernel.org,
	Satyam Sharma <satyam.sharma@...il.com>
Subject: Re: [PATCH] Reduce __print_symbol/sprint_symbol stack usage. (v3)

Gilboa Davara wrote:
> Hello all,

Hi, Gilboa

> (1) Problem:
> I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on
> i386 kernels, do_IRQ calls dump_stack which, down the path, uses
> print_symbol (display) and  sprint_symbol (format) to format and display
> the function name/address/module.
> Both function use stack based char array (~350 bytes) that, given the
> initial state (<512 bytes of stack space) may overrun the stack.
> II. (Comments - previous patches) Using spinlock protected static
> storage within these functions might block or even deadlock dump_stack
> (E.g. Crash within dump_stack itself)
> 
> (2) Solution:
> I. Break sprint_symbol into sprint_symbol (API functions; keeps the
> current interface) and sprint_symbol_helper (helper function with
> minimal local storage). 
> II. Replace the char array in __print_symbol with two spinlock protected
> static char arrays; call the __sprint_symbol helper function instead of
> sprint_symbol.
> III. Ignore the spinlock if oops_in_progress is set.

This is getting more and more convoluted :(

The problem with the spinlock isn't just that during a panic, we can not 
trust the kernel structures enough to use spinlocks. It might well 
happen that lockdep code might want to use print_symbol (and I think it 
does, so this is not just theoretical) to dump the stack when someone 
calls spin_lock_irqsave.

But now, because print_symbol itself uses spin_lock_irqsave, we might 
get into a recursive situation and a produce a deadlock.

On the other hand, if you take the other approach of reducing the stack 
usage by creating a printk_symbol interface, the stack usage would drop 
from 350 bytes to 128 bytes and your problem would go away entirely.

-- 
Paulo Marques - www.grupopie.com

"All I ask is a chance to prove that money can't make me happy."
-
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/