Kees Cook <keescook@xxxxxxxxxxxx> writes: > On Wed, Mar 5, 2014 at 6:50 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: >> Kees Cook <keescook@xxxxxxxxxxxx> writes: >>> [+x86 folks] >>> >>> On Tue, Mar 4, 2014 at 7:57 AM, Linus Torvalds >>> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> On Mon, Mar 3, 2014 at 3:55 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>>>> This got NAKed, please don't apply -- this patch works for x86 and >>>>> ARM, but may cause problems for others: >>>> >>>> I'd much rather fix x86 and ARM, than worry about avr32. >>>> >>>> Priorities, people. >>>> >>>> Somebody who knows how "fix this properly" is supposed to work? >>> >>> I have not yet had a chance to more carefully examine the options, but >>> AIUI, the problem is that (at least) the "per cpu" variables are >>> neither absolute nor relative addresses from a relocation perspective. >>> They're relative to the per cpu area, but the linker tools don't know >>> about that state. So, I think, to fix this correctly, we need to teach >>> the linker tools about this third state. This may also help >>> arch/x86/tools/relocs, which is currently using a whitelist for >>> mis-identified variables. >> >> Well, __per_cpu_start points into a real section, within the discarded >> init region. Makes me wonder why it's zero in /proc/kallsyms (it is on >> my Ubuntu system here too). >> >> ... digging ... >> >> Ah, the zero-based percpu patches, of course. Gah. >> >> How's this? Did I break IA64? >> >> === >> kallsyms: make zero-based __per_cpu_start & __per_cpu_end absolute symbols. >> >> Andy reported that x86-64 with CONFIG_RANDOMIZE_BASE has bogus values >> for __per_cpu_start and __per_cpu_end in /proc/kallsyms: > > Well, just to make sure it's clear: __per_cpu_start/_end are just > markers, and everything between them is mishandled as well, not just > things named "__per_cpu" ... Gah... they should all be absolute, really, but that's going to be harder. >> - PERCPU_INPUT(cacheline) \ >> + VMLINUX_SYMBOL(__per_cpu_start) = ABSOLUTE(.); \ >> + __PERCPU_INPUT(cacheline) \ >> + VMLINUX_SYMBOL(__per_cpu_end) = ABSOLUTE(.); \ > > I think this portion interacts badly with the x86 relocs tool which is > trying to find the per_cpu area via percpu_init(), which looks for the > section name ".data..percpu". What is "the x86 relocs tool"? Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|