Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170810172615.51965-19-thgarnie@google.com>
Date: Thu, 10 Aug 2017 10:26:10 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: Herbert Xu <herbert@...dor.apana.org.au>,
	"David S . Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H . Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Arnd Bergmann <arnd@...db.de>,
	Thomas Garnier <thgarnie@...gle.com>,
	Matthias Kaehlcke <mka@...omium.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Radim Krčmář <rkrcmar@...hat.com>,
	Joerg Roedel <joro@...tes.org>,
	Tom Lendacky <thomas.lendacky@....com>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...e.de>,
	Brian Gerst <brgerst@...il.com>,
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>,
	Pavel Machek <pavel@....cz>,
	Tejun Heo <tj@...nel.org>,
	Christoph Lameter <cl@...ux.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Chris Metcalf <cmetcalf@...lanox.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Christopher Li <sparse@...isli.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Lukas Wunner <lukas@...ner.de>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Dou Liyang <douly.fnst@...fujitsu.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Alexei Starovoitov <ast@...nel.org>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Kees Cook <keescook@...omium.org>,
	Rik van Riel <riel@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Waiman Long <longman@...hat.com>,
	Kyle Huey <me@...ehuey.com>,
	Peter Foley <pefoley2@...oley.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Michal Hocko <mhocko@...e.com>,
	Matthew Wilcox <mawilcox@...rosoft.com>,
	"H . J . Lu" <hjl.tools@...il.com>,
	Paul Bolle <pebolle@...cali.nl>,
	Rob Landley <rob@...dley.net>,
	Baoquan He <bhe@...hat.com>,
	Daniel Micay <danielmicay@...il.com>
Cc: x86@...nel.org,
	linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	xen-devel@...ts.xenproject.org,
	kvm@...r.kernel.org,
	linux-pm@...r.kernel.org,
	linux-arch@...r.kernel.org,
	linux-sparse@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: [RFC v2 18/23] x86/relocs: Handle DYN relocations for PIE support

Change the relocation tool to correctly handle DYN/PIE kernel where
the relocation table does not reference symbols and percpu support is
not needed. Also add support for R_X86_64_RELATIVE relocations that can
be handled like a 64-bit relocation due to the usage of -Bsymbolic.

Position Independent Executable (PIE) support will allow to extended the
KASLR randomization range below the -2G memory limit.

Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
---
 arch/x86/tools/relocs.c | 74 +++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 65 insertions(+), 9 deletions(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 73eb7fd4aec4..70f523dd68ff 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -642,6 +642,13 @@ static void add_reloc(struct relocs *r, uint32_t offset)
 	r->offset[r->count++] = offset;
 }
 
+/* Relocation found in a DYN binary, support only for 64-bit PIE */
+static int is_dyn_reloc(struct section *sec)
+{
+	return ELF_BITS == 64 && ehdr.e_type == ET_DYN &&
+		sec->shdr.sh_info == SHT_NULL;
+}
+
 static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
 			Elf_Sym *sym, const char *symname))
 {
@@ -652,6 +659,7 @@ static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
 		Elf_Sym *sh_symtab;
 		struct section *sec_applies, *sec_symtab;
 		int j;
+		int dyn_reloc = 0;
 		struct section *sec = &secs[i];
 
 		if (sec->shdr.sh_type != SHT_REL_TYPE) {
@@ -660,14 +668,20 @@ static void walk_relocs(int (*process)(struct section *sec, Elf_Rel *rel,
 		sec_symtab  = sec->link;
 		sec_applies = &secs[sec->shdr.sh_info];
 		if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) {
-			continue;
+			if (!is_dyn_reloc(sec_applies))
+				continue;
+			dyn_reloc = 1;
 		}
 		sh_symtab = sec_symtab->symtab;
 		sym_strtab = sec_symtab->link->strtab;
 		for (j = 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) {
 			Elf_Rel *rel = &sec->reltab[j];
-			Elf_Sym *sym = &sh_symtab[ELF_R_SYM(rel->r_info)];
-			const char *symname = sym_name(sym_strtab, sym);
+			Elf_Sym *sym = NULL;
+			const char *symname = NULL;
+			if (!dyn_reloc) {
+				sym = &sh_symtab[ELF_R_SYM(rel->r_info)];
+				symname = sym_name(sym_strtab, sym);
+			}
 
 			process(sec, rel, sym, symname);
 		}
@@ -746,16 +760,21 @@ static int is_percpu_sym(ElfW(Sym) *sym, const char *symname)
 		strncmp(symname, "init_per_cpu_", 13);
 }
 
-
 static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 		      const char *symname)
 {
 	unsigned r_type = ELF64_R_TYPE(rel->r_info);
 	ElfW(Addr) offset = rel->r_offset;
-	int shn_abs = (sym->st_shndx == SHN_ABS) && !is_reloc(S_REL, symname);
+	int shn_abs = 0;
+	int dyn_reloc = is_dyn_reloc(sec);
 
-	if (sym->st_shndx == SHN_UNDEF)
-		return 0;
+	if (!dyn_reloc) {
+		shn_abs = (sym->st_shndx == SHN_ABS) &&
+			!is_reloc(S_REL, symname);
+
+		if (sym->st_shndx == SHN_UNDEF)
+			return 0;
+	}
 
 	/*
 	 * Adjust the offset if this reloc applies to the percpu section.
@@ -769,6 +788,9 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 		break;
 
 	case R_X86_64_PC32:
+		if (dyn_reloc)
+			die("PC32 reloc in PIE DYN binary");
+
 		/*
 		 * PC relative relocations don't need to be adjusted unless
 		 * referencing a percpu symbol.
@@ -783,7 +805,7 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 		/*
 		 * References to the percpu area don't need to be adjusted.
 		 */
-		if (is_percpu_sym(sym, symname))
+		if (!dyn_reloc && is_percpu_sym(sym, symname))
 			break;
 
 		if (shn_abs) {
@@ -814,6 +836,14 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 			add_reloc(&relocs32, offset);
 		break;
 
+	case R_X86_64_RELATIVE:
+		/*
+		 * -Bsymbolic means we don't need the addend and we can reuse
+		 * the original relocs64.
+		 */
+		add_reloc(&relocs64, offset);
+		break;
+
 	default:
 		die("Unsupported relocation type: %s (%d)\n",
 		    rel_type(r_type), r_type);
@@ -1044,6 +1074,21 @@ static void emit_relocs(int as_text, int use_real_mode)
 	}
 }
 
+/* Print a different header based on the type of relocation */
+static void print_reloc_header(struct section *sec) {
+	static int header_printed = 0;
+	int header_type = is_dyn_reloc(sec) ? 2 : 1;
+
+	if (header_printed == header_type)
+		return;
+	header_printed = header_type;
+
+	if (header_type == 2)
+		printf("reloc type\toffset\tvalue\n");
+	else
+		printf("reloc section\treloc type\tsymbol\tsymbol section\n");
+}
+
 /*
  * As an aid to debugging problems with different linkers
  * print summary information about the relocs.
@@ -1053,6 +1098,18 @@ static void emit_relocs(int as_text, int use_real_mode)
 static int do_reloc_info(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 				const char *symname)
 {
+
+	print_reloc_header(sec);
+
+#if ELF_BITS == 64
+	if (is_dyn_reloc(sec)) {
+		printf("%s\t0x%lx\t0x%lx\n",
+		       rel_type(ELF_R_TYPE(rel->r_info)),
+		       rel->r_offset,
+		       rel->r_addend);
+		return 0;
+	}
+#endif
 	printf("%s\t%s\t%s\t%s\n",
 		sec_name(sec->shdr.sh_info),
 		rel_type(ELF_R_TYPE(rel->r_info)),
@@ -1063,7 +1120,6 @@ static int do_reloc_info(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym,
 
 static void print_reloc_info(void)
 {
-	printf("reloc section\treloc type\tsymbol\tsymbol section\n");
 	walk_relocs(do_reloc_info);
 }
 
-- 
2.14.0.434.g98096fd7a8-goog

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.