On Mon, Feb 24, 2014 at 5:29 PM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Kees Cook <keesc...@chromium.org> writes: >> From: Andy Honig <aho...@google.com> >> >> Currently symbols that are absolute addresses are incorrectly >> displayed in /proc/kallsyms if the kernel is loaded with kASLR. >> >> The problem was that the scripts/kallsyms.c file which generates >> the array of symbol names and addresses uses an relocatable value >> for all symbols, even absolute symbols. This patch fixes that. > > Hi Andy, Kees, > > This is not a good patch. See the commit where this was > introduced: > > [PATCH] relocatable kernel: Fix kallsyms on avr32 after relocatable kernel > changes > > o On some platforms like avr32, section init comes before .text and > not necessarily a symbol's relative position w.r.t _text is positive. > In such cases assembler detects the overflow and emits warning. This > patch fixes it. > > Did you just break avr32? > > And absolute symbols are supposed to be handled in the other branch: > > for (i = 0; i < table_cnt; i++) { > if (toupper(table[i].sym[0]) != 'A') { > if (_text <= table[i].addr) > printf("\tPTR\t_text + %#llx\n", > table[i].addr - _text); > else > printf("\tPTR\t_text - %#llx\n", > _text - table[i].addr); > } else { > printf("\tPTR\t%#llx\n", table[i].addr); > } > } > > __per_cpu_start is not an absolute symbol anyway. > > You need to fix this properly. > Rusty.
Hm, yeah, it seems we need another class of variable. The per_cpu stuff is technically relative, but it's not relocated, since it's not relative to the text location. We'll see how to do this more sanely. Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/