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:	Tue, 28 Jan 2014 12:25:15 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Richard Weinberger <richard@....at>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Kees Cook <keescook@...omium.org>,
	Cong Ding <dinggnu@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mathias Krause <minipli@...glemail.com>,
	Michael Davidson <md@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Wei Yongjun <yongjun_wei@...ndmicro.com.cn>
Subject: Re: [GIT PULL] x86/kaslr for v3.14

On Tue, Jan 28, 2014 at 12:15 PM, Borislav Petkov <bp@...en8.de> wrote:
>
> Shouldn't we hold that down in the Kconfig help text of DEBUG_INFO?
> Something like:
>
> "You don't need to enable this if you want symbolic names for kernel
> objects. Enable CONFIG_KALLSYMS instead."

Probably. And then we should make sure that allyesconfig/allmodconfig
don't pick it.

There *are* reasonable uses for DEBUG_INFO:

 - if you very actively and extensively use kgdb, DEBUG_INFO is very useful.

 - distros might want to build distro kernels with DEBUG_INFO for the
kernel debug package

but for most kernel developers, DEBUG_INFO really just bloats things
and makes the build much *much* slower, for very little gain. Sure,
you get line numbers, but let's face it, it's not that hard to just do
"x/20i <address>" and trying to match it up with the generated code
instead. And since "just match it up" model works with user-reported
oopses of random kernels, you had better be able and willing to do
that *anyway*.

If most of the oopses you decode are on your own machine with your own
kernel, you might want to try to learn to be more careful when writing
code. And I'm not even kidding.

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

Powered by blists - more mailing lists