linux-kernel - Re: [BUG] perf: bogus correlation of kernel symbols

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1306089922.1806.27.camel@dan>
Date:	Sun, 22 May 2011 14:45:22 -0400
From:	Dan Rosenberg <drosenberg@...curity.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, davej@...hat.com,
	kees.cook@...onical.com, davem@...emloft.net, eranian@...gle.com,
	torvalds@...ux-foundation.org, adobriyan@...il.com,
	penberg@...nel.org, hpa@...or.com
Subject: Re: [BUG] perf: bogus correlation of kernel symbols

On Fri, 2011-05-20 at 15:11 +0200, Ingo Molnar wrote:
> * Dan Rosenberg <drosenberg@...curity.com> wrote:
> 
> > On Fri, 2011-05-20 at 14:07 +0200, Ingo Molnar wrote:
> > > * Dan Rosenberg <drosenberg@...curity.com> wrote:
> > > 
> > > > I was able to boot a relocatable kernel with the decompression location at a 
> > > > hard-coded offset without too much trouble.  Everything seems to work fine.
> > > 
> > > Nice!
> > > 

A progress update, and a number of questions.

The randomization itself is working fine with the following hack in
arch/x86/boot/compressed/head_32.S:

#ifdef CONFIG_RELOCATABLE
	movl	%ebp, %ebx
#ifdef CONFIG_RANDOMIZE_BASE
	rdtsc
	shll	$0x8, %eax
	andl	$0x3ffffff, %eax
	addl	%eax, %ebx
#endif
	movl	BP_kernel_alignment(%esi), %eax
	decl	%eax
	addl	%eax, %ebx
	notl	%eax
	andl	%eax
#endif

That brings me to my first two questions:

1. Is it ok to assume the existence of rdtsc?  If not, what are other
ways of gathering entropy early in the boot process?  If this is the
approach that's going to be taken, system uptime potentially becomes
useful for attackers.  Any thoughts on how to address this?

2. The current default physical alignment is 16mb as a result of this
patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ceefccc93932b920a8ec6f35f596db05202a12fe

Having 16mb alignment greatly restricts the amount of usable entropy for
randomization.  It seems an alternate solution to the problem the above
patch addresses is reverting back to 1mb alignment (or 2/4 mb if that
has performance benefits) and enforcing a 16mb minimum physical start
for relocatable kernels by bumping it up in the boot code if necessary.
Would this be possible?  I'd like to avoid requiring distros to touch
CONFIG_PHYSICAL_ALIGN (and risk breaking things) in order to have more
useful randomization.

A few more questions arose during my efforts:

3. The current hack I'm using to determine the offset to reverse apply
to symbol output looks something like this:

unsigned long kptr_adjust = ((unsigned long)_text &
~(CONFIG_PHYSICAL_ALIGN-1)) - (PAGE_OFFSET + CONFIG_PHYSICAL_START);

Is it safe to assume that kernel .text is the first thing in a
decompressed kernel image?  If not, any other suggestions?  It seemed
easier to compute this in the decompressed kernel at runtime rather than
try to figure out a way to pass the actual decompression address from
the boot stage to the main kernel.

4. What kind of behavior do people want with %pK and kptr_restrict?  If
possible, I'd like to find a way that perf users can have the benefits
of this feature and still have usable symbol support.  However, module
symbols are a bit tricky, since they're not being relocated with the
rest of the kernel, and it doesn't seem meaningful to reverse-apply the
same offset in module symbol output.  Perhaps a separate format
specifier should be introduced to differentiate symbols that need to be
offset?

Basically, we've got kernel .text symbols, module symbols, and dynamic
kernel pointers, and I'm not sure with what granularity people are
interested in hiding them.  It seems perf at least wants more than "all
or nothing".

5. I'd like some more opinions on moving the IDT.  So far, the two
options are using a fixed mapping similar to the F00F bug fix, and
allocating it percpu at runtime.

Looking forward to feedback, criticism, disgust, etc.

Regards,
Dan

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