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 20:48:23 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"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


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, Jan 28, 2014 at 9:05 AM, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Well, I often use the hex numbers to look them up and disassemble them
> > in a vmlinux via gdb and 'list *0x1234123412341234' - where the
> > vmlinux has no debuginfo. (Debuginfo takes longer to build so I
> > generally build without it.)
> 
> Why the heck wouldn't you do that? Just do
> 
>    list schedule+0x45
> 
> instead.
> 
> > AFAICS this won't work in a symbol-less vmlinux. Is there some trick
> > to do it with gdb?
> 
> Why would you have a symbol-less vmlinux? The only reason to strip 
> vmlinux is because you were crazy enough to build with 

I don't think I ever stripped a vmlinux in my life, and I definitely 
didn't strip this one:

  phoenix:~/linux/linux> file vmlinux
  vmlinux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=0x239d56b40bb654ddd2dd704e6b585d5c90de4e12, not stripped

> CONFIG_DEBUG_INFO and the damn debug info is so large that it won't 
> fit on your root partition. But dammit, if you build with debug_info 
> and then strip the end result, you're just insane. [...]

So, to quote myself from 2 sentences ago:

> > vmlinux has no debuginfo. (Debuginfo takes longer to build so I 
> > generally build without it.)

I really meant it when I said I build without debuginfo! :)

So, when I build a kernel, such as with a regular 'make defconfig', 
the following happens in gdb:

  Reading symbols from /home/mingo/tip/vmlinux...(no debugging symbols found)...done.
  (gdb) list schedule+0x45
  No symbol table is loaded.  Use the "file" command.

Is there a way to resolve schedule+0x45 in a regular vmlinux? It was 
an honest question.

> [...] You made your build take ten times longer, use ten times more 
> diskspace, and then you throw it all away. Crazy.

It's so crazy that I in fact try to force off debuginfo for all my 
builds, even randconfig ones:

  config DEBUG_INFO
        bool "Compile the kernel with debug info"
        depends on DEBUG_KERNEL
        # too slow build in QA
        depends on 0

> So I don't think the symbol-less version is worth even worrying 
> about. You do want to build with KALLSYMS (or whatever the config 
> option is called), so that the symbolic name is worth something, but 
> once you have the symbolc name, you're good unless you did something 
> terminally stupid.

Hm, I have kallsyms on - it's a regular 'make defconfig':

  phoenix:~/linux/linux> grep KALL .config
  CONFIG_KALLSYMS=y

I might be doing something terminally stupid.

> Btw, we should make it harder to enable CONFIG_DEBUG_INFO. [...]

It's really not set:

  phoenix:~/linux/linux> grep DEBUG_INFO .config
  # CONFIG_DEBUG_INFO is not set

> [...] It's a f*cking pain. It's particularly nasty when you do "make 
> allmodconfig" and it enables debug-info and makes the build take 
> forever and waste diskspace - but nobody sane actually *boots* the 
> end result, so that debug info is all pointless.

I actually boot (almost-)allmod and allyesconfigs - still I disable 
DEBUG_INFO because it's such a strain on our planet's climate.

Thanks,

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