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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1305913261.20623.12.camel@dan>
Date:	Fri, 20 May 2011 13:41:01 -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
Subject: Re: [BUG] perf: bogus correlation of kernel symbols

On Fri, 2011-05-20 at 15:11 +0200, Ingo Molnar wrote:

> We need to allocate the IDT dynamically: just kmalloc() it, update idt_descr 
> and do a load_idt(). Double check places that modify idt_descr or use 
> idt_table.
> 
> Note, you could do this as a side effect of a nice performance optimization: 
> would you be interested in allocating it in the percpu area, using 
> percpu_alloc()? That way the IDT is distributed between CPUs - this has 
> scalability advantages on NUMA systems and maybe even on SMP.
> 

Any suggestions on when this allocation should take place?  I'm hesitant
to touch anything in arch/x86/kernel/head_32.S, where the IDT is setup
and lidt idt_descr is called (on x86-32 anyway).  That means at some
point I'd have to copy the table into a region allocated with
alloc_percpu() and set up a new descriptor.  Seems like this should
happen before IRQ is enabled, but I'm not sure about the best place.

Also, I'd still welcome suggestions on generating entropy so early in
the boot process as to randomize the location at which the kernel is
decompressed.

On a related note, would there be obstacles to marking the IDT as
read-only?

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