linux-kernel - Re: [GIT PULL] x86/kaslr for v3.14

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 21:49:06 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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:25:15PM -0800, Linus Torvalds wrote:
> Probably. And then we should make sure that allyesconfig/allmodconfig
> don't pick it.

I'd need to think about that a bit longer as scripts/kconfig/conf.c goes
and sets those. Unless someone has a better idea...

> There *are* reasonable uses for DEBUG_INFO:
> 
>  - if you very actively and extensively use kgdb, DEBUG_INFO is very useful.

Right, and at least KGDB depends on it. I was going to suggest to hide
it and make only tools select it but...

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

Yes. SUSE uses crash to analyze dumps and for that it needs -g symbols
and other distros I'm sure too in some fashion.

> but for most kernel developers, DEBUG_INFO really just bloats things
> and makes the build much *much* slower, for very little gain.

Right, your discussion kinda made me aware of this - I hadn't realized
that KALLSYMS is enough.

> 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*.

Hohumm.

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

Haha.

Ok, here's the help text hunk:

---
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index dbf94a7d25a8..73b36a1624ec 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -126,7 +126,11 @@ config DEBUG_INFO
 	  This adds debug symbols to the kernel and modules (gcc -g), and
 	  is needed if you intend to use kernel crashdump or binary object
 	  tools like crash, kgdb, LKCD, gdb, etc on the kernel.
-	  Say Y here only if you plan to debug the kernel.
+
+	  If you only want to have symbols in kernel traces and are not
+	  going to need support for those tools above, you don't need
+	  to enable this as it is a huge bloat and build slowdown.
+	  Enable CONFIG_KALLSYMS instead.
 
 	  If unsure, say N.
 

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/