| Message ID | 20170718223333.110371-21-thgarnie@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/18/17 15:33, Thomas Garnier wrote: > The x86 relocation tool generates a list of 32-bit signed integers. There > was no need to use 64-bit integers because all addresses where above the 2G > top of the memory. > > This change add a large-reloc option to generate 64-bit unsigned integers. > It can be used when the kernel plan to go below the top 2G and 32-bit > integers are not enough. Why on Earth? This would only be necessary if the *kernel itself* was more than 2G, which isn't going to happen for the forseeable future. -hpa
On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 07/18/17 15:33, Thomas Garnier wrote: >> The x86 relocation tool generates a list of 32-bit signed integers. There >> was no need to use 64-bit integers because all addresses where above the 2G >> top of the memory. >> >> This change add a large-reloc option to generate 64-bit unsigned integers. >> It can be used when the kernel plan to go below the top 2G and 32-bit >> integers are not enough. > > Why on Earth? This would only be necessary if the *kernel itself* was > more than 2G, which isn't going to happen for the forseeable future. Because the relocation integer is an absolute address, not an offset in the binary. Next iteration, I can try using a 32-bit offset for everyone. > > -hpa >
On 07/19/17 15:47, Thomas Garnier wrote: > On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> On 07/18/17 15:33, Thomas Garnier wrote: >>> The x86 relocation tool generates a list of 32-bit signed integers. There >>> was no need to use 64-bit integers because all addresses where above the 2G >>> top of the memory. >>> >>> This change add a large-reloc option to generate 64-bit unsigned integers. >>> It can be used when the kernel plan to go below the top 2G and 32-bit >>> integers are not enough. >> >> Why on Earth? This would only be necessary if the *kernel itself* was >> more than 2G, which isn't going to happen for the forseeable future. > > Because the relocation integer is an absolute address, not an offset > in the binary. Next iteration, I can try using a 32-bit offset for > everyone. It is an absolute address *as the kernel was originally linked*, for obvious reasons. -hpa
On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 07/19/17 15:47, Thomas Garnier wrote: >> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> wrote: >>> On 07/18/17 15:33, Thomas Garnier wrote: >>>> The x86 relocation tool generates a list of 32-bit signed integers. There >>>> was no need to use 64-bit integers because all addresses where above the 2G >>>> top of the memory. >>>> >>>> This change add a large-reloc option to generate 64-bit unsigned integers. >>>> It can be used when the kernel plan to go below the top 2G and 32-bit >>>> integers are not enough. >>> >>> Why on Earth? This would only be necessary if the *kernel itself* was >>> more than 2G, which isn't going to happen for the forseeable future. >> >> Because the relocation integer is an absolute address, not an offset >> in the binary. Next iteration, I can try using a 32-bit offset for >> everyone. > > It is an absolute address *as the kernel was originally linked*, for > obvious reasons. Sure when the kernel was just above 0xffffffff80000000, it doesn't work when it goes down to 0xffffffff00000000. That's why using an offset might make more sense in general. > > -hpa >
<cmetcalf@mellanox.com>,"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,Andrew Morton <akpm@linux-foundation.org>,Christopher Li <sparse@chrisli.org>,Dou Liyang <douly.fnst@cn.fujitsu.com>,Masahiro Yamada <yamada.masahiro@socionext.com>,Daniel Borkmann <daniel@iogearbox.net>,Markus Trippelsdorf <markus@trippelsdorf.de>,Peter Foley <pefoley2@pefoley.com>,Steven Rostedt <rostedt@goodmis.org>,Tim Chen <tim.c.chen@linux.intel.com>,Ard Biesheuvel <ard.biesheuvel@linaro.org>,Catalin Marinas <catalin.marinas@arm.com>,Matthew Wilcox <mawilcox@microsoft.com>,Michal Hocko <mhocko@suse.com>,Rob Landley <rob@landley.net>,Jiri Kosina <jkosina@suse.cz>,"H . J . Lu" <hjl.tools@gmail.com>,Paul Bolle <pebolle@tiscali.nl>,Baoquan He <bhe@redhat.com>,Daniel Micay <danielmicay@gmail.com>,the arch/x86 maintainers <x86@kernel.org>,linux-crypto@vger.kernel.org,LKML <linux-kernel@vger.kernel.org>,xen-devel@lists.xenproject.org,kvm list <kvm@vger.kernel.org>,Linux PM list <linux-pm@vger.kernel.org>,linux-arch <linux-arch@vger.kernel.org>,linux-sparse@vger.kernel.org,Kernel Hardening <kernel-hardening@lists.openwall.com> From: hpa@zytor.com Message-ID: <0EF6FAAA-A99C-4F0D-9E4A-AD25E93957FB@zytor.com> On July 19, 2017 4:25:56 PM PDT, Thomas Garnier <thgarnie@google.com> wrote: >On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> On 07/19/17 15:47, Thomas Garnier wrote: >>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> >wrote: >>>> On 07/18/17 15:33, Thomas Garnier wrote: >>>>> The x86 relocation tool generates a list of 32-bit signed >integers. There >>>>> was no need to use 64-bit integers because all addresses where >above the 2G >>>>> top of the memory. >>>>> >>>>> This change add a large-reloc option to generate 64-bit unsigned >integers. >>>>> It can be used when the kernel plan to go below the top 2G and >32-bit >>>>> integers are not enough. >>>> >>>> Why on Earth? This would only be necessary if the *kernel itself* >was >>>> more than 2G, which isn't going to happen for the forseeable >future. >>> >>> Because the relocation integer is an absolute address, not an offset >>> in the binary. Next iteration, I can try using a 32-bit offset for >>> everyone. >> >> It is an absolute address *as the kernel was originally linked*, for >> obvious reasons. > >Sure when the kernel was just above 0xffffffff80000000, it doesn't >work when it goes down to 0xffffffff00000000. That's why using an >offset might make more sense in general. > >> >> -hpa >> What is the motivation for changing the pre linked address at all?
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index 70f523dd68ff..19b3e6c594b1 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -12,8 +12,14 @@ static Elf_Ehdr ehdr; +#if ELF_BITS == 64 +typedef uint64_t rel_off_t; +#else +typedef uint32_t rel_off_t; +#endif + struct relocs { - uint32_t *offset; + rel_off_t *offset; unsigned long count; unsigned long size; }; @@ -627,7 +633,7 @@ static void print_absolute_relocs(void) printf("\n"); } -static void add_reloc(struct relocs *r, uint32_t offset) +static void add_reloc(struct relocs *r, rel_off_t offset) { if (r->count == r->size) { unsigned long newsize = r->size + 50000; @@ -983,26 +989,48 @@ static void sort_relocs(struct relocs *r) qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs); } -static int write32(uint32_t v, FILE *f) +static int write32(rel_off_t rel, FILE *f) { - unsigned char buf[4]; + unsigned char buf[sizeof(uint32_t)]; + uint32_t v = (uint32_t)rel; put_unaligned_le32(v, buf); - return fwrite(buf, 1, 4, f) == 4 ? 0 : -1; + return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1; } -static int write32_as_text(uint32_t v, FILE *f) +static int write32_as_text(rel_off_t rel, FILE *f) { + uint32_t v = (uint32_t)rel; return fprintf(f, "\t.long 0x%08"PRIx32"\n", v) > 0 ? 0 : -1; } -static void emit_relocs(int as_text, int use_real_mode) +static int write64(rel_off_t rel, FILE *f) +{ + unsigned char buf[sizeof(uint64_t)]; + uint64_t v = (uint64_t)rel; + + put_unaligned_le64(v, buf); + return fwrite(buf, 1, sizeof(buf), f) == sizeof(buf) ? 0 : -1; +} + +static int write64_as_text(rel_off_t rel, FILE *f) +{ + uint64_t v = (uint64_t)rel; + return fprintf(f, "\t.quad 0x%016"PRIx64"\n", v) > 0 ? 0 : -1; +} + +static void emit_relocs(int as_text, int use_real_mode, int use_large_reloc) { int i; - int (*write_reloc)(uint32_t, FILE *) = write32; + int (*write_reloc)(rel_off_t, FILE *); int (*do_reloc)(struct section *sec, Elf_Rel *rel, Elf_Sym *sym, const char *symname); + if (use_large_reloc) + write_reloc = write64; + else + write_reloc = write32; + #if ELF_BITS == 64 if (!use_real_mode) do_reloc = do_reloc64; @@ -1013,6 +1041,9 @@ static void emit_relocs(int as_text, int use_real_mode) do_reloc = do_reloc32; else do_reloc = do_reloc_real; + + /* Large relocations only for 64-bit */ + use_large_reloc = 0; #endif /* Collect up the relocations */ @@ -1036,8 +1067,13 @@ static void emit_relocs(int as_text, int use_real_mode) * gas will like. */ printf(".section \".data.reloc\",\"a\"\n"); - printf(".balign 4\n"); - write_reloc = write32_as_text; + if (use_large_reloc) { + printf(".balign 8\n"); + write_reloc = write64_as_text; + } else { + printf(".balign 4\n"); + write_reloc = write32_as_text; + } } if (use_real_mode) { @@ -1131,7 +1167,7 @@ static void print_reloc_info(void) void process(FILE *fp, int use_real_mode, int as_text, int show_absolute_syms, int show_absolute_relocs, - int show_reloc_info) + int show_reloc_info, int use_large_reloc) { regex_init(use_real_mode); read_ehdr(fp); @@ -1153,5 +1189,5 @@ void process(FILE *fp, int use_real_mode, int as_text, print_reloc_info(); return; } - emit_relocs(as_text, use_real_mode); + emit_relocs(as_text, use_real_mode, use_large_reloc); } diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h index 1d23bf953a4a..cb771cc4412d 100644 --- a/arch/x86/tools/relocs.h +++ b/arch/x86/tools/relocs.h @@ -30,8 +30,8 @@ enum symtype { void process_32(FILE *fp, int use_real_mode, int as_text, int show_absolute_syms, int show_absolute_relocs, - int show_reloc_info); + int show_reloc_info, int use_large_reloc); void process_64(FILE *fp, int use_real_mode, int as_text, int show_absolute_syms, int show_absolute_relocs, - int show_reloc_info); + int show_reloc_info, int use_large_reloc); #endif /* RELOCS_H */ diff --git a/arch/x86/tools/relocs_common.c b/arch/x86/tools/relocs_common.c index acab636bcb34..9cf1391af50a 100644 --- a/arch/x86/tools/relocs_common.c +++ b/arch/x86/tools/relocs_common.c @@ -11,14 +11,14 @@ void die(char *fmt, ...) static void usage(void) { - die("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode]" \ - " vmlinux\n"); + die("relocs [--abs-syms|--abs-relocs|--reloc-info|--text|--realmode|" \ + "--large-reloc] vmlinux\n"); } int main(int argc, char **argv) { int show_absolute_syms, show_absolute_relocs, show_reloc_info; - int as_text, use_real_mode; + int as_text, use_real_mode, use_large_reloc; const char *fname; FILE *fp; int i; @@ -29,6 +29,7 @@ int main(int argc, char **argv) show_reloc_info = 0; as_text = 0; use_real_mode = 0; + use_large_reloc = 0; fname = NULL; for (i = 1; i < argc; i++) { char *arg = argv[i]; @@ -53,6 +54,10 @@ int main(int argc, char **argv) use_real_mode = 1; continue; } + if (strcmp(arg, "--large-reloc") == 0) { + use_large_reloc = 1; + continue; + } } else if (!fname) { fname = arg; @@ -74,11 +79,11 @@ int main(int argc, char **argv) if (e_ident[EI_CLASS] == ELFCLASS64) process_64(fp, use_real_mode, as_text, show_absolute_syms, show_absolute_relocs, - show_reloc_info); + show_reloc_info, use_large_reloc); else process_32(fp, use_real_mode, as_text, show_absolute_syms, show_absolute_relocs, - show_reloc_info); + show_reloc_info, use_large_reloc); fclose(fp); return 0; }
The x86 relocation tool generates a list of 32-bit signed integers. There was no need to use 64-bit integers because all addresses where above the 2G top of the memory. This change add a large-reloc option to generate 64-bit unsigned integers. It can be used when the kernel plan to go below the top 2G and 32-bit integers are not enough. Signed-off-by: Thomas Garnier <thgarnie@google.com> --- arch/x86/tools/relocs.c | 60 +++++++++++++++++++++++++++++++++--------- arch/x86/tools/relocs.h | 4 +-- arch/x86/tools/relocs_common.c | 15 +++++++---- 3 files changed, 60 insertions(+), 19 deletions(-)