Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled by fixing up the ELF object.

Signed-off-by Zachary Amsden <[email protected]>

Index: linux-2.6.21/arch/i386/kernel/entry.S
===================================================================

arch/i386/kernel/entry.S +0 -4

@@ -305,16 +305,12 @@ sysenter_past_esp:
 	pushl $(__USER_CS)
 	CFI_ADJUST_CFA_OFFSET 4
 	/*CFI_REL_OFFSET cs, 0*/
-#ifndef CONFIG_COMPAT_VDSO
 	/*
 	 * Push current_thread_info()->sysenter_return to the stack.
 	 * A tiny bit of offset fixup is necessary - 4*4 means the 4 words
 	 * pushed above; +8 corresponds to copy_thread's esp0 setting.
 	 */
 	pushl (TI_sysenter_return-THREAD_SIZE+8+4*4)(%esp)
-#else
-	pushl $SYSENTER_RETURN
-#endif
 	CFI_ADJUST_CFA_OFFSET 4
 	CFI_REL_OFFSET eip, 0
 

Index: linux-2.6.21/arch/i386/kernel/sysenter.c
===================================================================

arch/i386/kernel/sysenter.c +16 -0

@@ -72,6 +72,99 @@ extern const char vsyscall_int80_start, 
 extern const char vsyscall_sysenter_start, vsyscall_sysenter_end;
 static struct page *syscall_pages[1];
 
+#ifdef CONFIG_COMPAT_VDSO
+static void fixup_vsyscall_elf(char *page)
+{
+	Elf32_Ehdr *hdr;
+	Elf32_Shdr *sechdrs;
+	Elf32_Phdr *phdr;
+	char *secstrings;
+	int i, j, n;
+
+	hdr = (Elf32_Ehdr *)page;
+	
+	printk("Remapping vsyscall page to %08x\n", (unsigned int)VDSO_HIGH_BASE);
+
+	/* Sanity checks against insmoding binaries or wrong arch,
+           weird elf version */
+	if (memcmp(hdr->e_ident, ELFMAG, 4) != 0 ||

arch/i386/kernel/sysenter.c +4 -0

+		if (!(sechdrs[i].sh_flags & SHF_ALLOC))
+			continue;
+
+		sechdrs[i].sh_addr += VDSO_HIGH_BASE;

arch/i386/kernel/sysenter.c +30 -0

+	}
+	phdr = (void *)hdr + hdr->e_phoff;
+	for (i = 0; i < hdr->e_phnum; i++) {
+		phdr[i].p_vaddr += VDSO_HIGH_BASE;
+		phdr[i].p_paddr += VDSO_HIGH_BASE;
+	}
+
+#if 0
+/* 
+ * To verify the binary image in memory is identical, linked in the VDSO page
+ * from a COMPAT_VDSO compile without this patch; then diff the two.  For a
+ * non-relocated fixmap, the VDSO image is identical.
+ */
+{
+	extern const char vsyscall_orig_start, vsyscall_orig_end;
+	int *l1 = (int *)page, *l2 = (int *)&vsyscall_orig_start;
+	int foo = vsyscall_orig_end - vsyscall_orig_start / 4;
+	for (i = 0; i < foo; i++) {
+		if (l1[i] != l2[i]) {
+			printk("vsyscall - delta [%03x] orig %08x new %08x\n",
+				i, l2[i], l1[i]);
+		}
+	}
+}
+#endif
+}
+#else /* !CONFIG_COMPAT_VDSO */
+static inline void fixup_vsyscall_elf(char *page) {}
+#endif /* CONFIG_COMPAT_VDSO */
+
 int __init sysenter_setup(void)
 {
 	void *syscall_page = (void *)get_zeroed_page(GFP_ATOMIC);

@@ -86,20 +179,22 @@ int __init sysenter_setup(void)
 		memcpy(syscall_page,
 		       &vsyscall_int80_start,

Quoted 4 lines · Zachary Amsden

Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled by fixing up the ELF object.

So does it actually work? Can you boot the broken distros with this in place?

Using sections is wrong; you should be going through the phdrs, and looking for PT_DYNAMIC for relocation.

Does anyone expect the symbolic info to be correct? It might be better to just stomp it so nobody gets any ideas.

On the other hand, we don't want to break compatibility with anything...

arch/i386/kernel/sysenter.c extern const char vsyscall_int80_start, · line 116

Quoted 6 lines

arch/i386/kernel/sysenter.c +4 -0

+		} else if (strcmp(secstrings+sechdrs[i].sh_name, ".dynamic") == 0) {
+			Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+			int tag;
+			while ((tag = (++dyn)->d_tag) != DT_NULL)

Um, no.

arch/i386/kernel/sysenter.c extern const char vsyscall_int80_start, · line 137

Quoted 8 lines

arch/i386/kernel/sysenter.c +6 -0

+		} else if (strcmp(secstrings+sechdrs[i].sh_name, ".useless") == 0) {
+			/* This is demonic; see vsyscall.lds.S; it puts the
+			 * .got in a section named .useless */
+			uint32_t *got = (void *)hdr + sechdrs[i].sh_offset;
+			*got += VDSO_HIGH_BASE;
+		}

This won't get relocated with one of the other relocations? It's in the text phdr.

Well testing that is not so fun. I installed SUSE Pro 9.0, and strings on ld.so contains the magic at_sysinfo assert! But it doesn't install TLS libraries, so I'll have to install them by hand.

In works - in theory. Look, a puppy!

Scratchbox is rumored to produce the fabled assertion even on modern distros by installing its own toolchain which includes the dreaded glibc.

I'm playing safe. Binary identical relocation to 0xffffe000 was my goal.

Quoted 9 lines

arch/i386/kernel/sysenter.c extern const char vsyscall_int80_start, · line 116

Quoted 6 lines

+ } else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {

arch/i386/kernel/sysenter.c +3 -0

+            Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+            int tag;
+            while ((tag = (++dyn)->d_tag) != DT_NULL)

Um, no.

Walk based on size instead?

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

+ } else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {

arch/i386/kernel/sysenter.c +3 -0

+            Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+            int tag;
+            while ((tag = (++dyn)->d_tag) != DT_NULL)

Quoted 5 lines

Quoted 3 lines

Um, no.

Walk based on size instead?

No, I was just complaining about the embedded assignment, before dinner, so I was overly terse.

Quoted 1 line

Quoted 1 line

Jeremy Fitzhardinge <[email protected]> 16.03.07 06:10 >>>

Quoted 4 lines · Zachary Amsden

Well testing that is not so fun. I installed SUSE Pro 9.0, and strings on ld.so contains the magic at_sysinfo assert! But it doesn't install TLS libraries, so I'll have to install them by hand.

Quoted 4 lines

In works - in theory. Look, a puppy!

Scratchbox is rumored to produce the fabled assertion even on modern distros by installing its own toolchain which includes the dreaded glibc.

I think Andi and Andrew have boxes which are afflicted.

Quoted 1 line

I'm playing safe. Binary identical relocation to 0xffffe000 was my goal.

Yeah, fair enough. But as Eric likes to keep pointing out, an executable ELF file need not have any sections at all, so the only safe course for anything "real" is via the section headers.

So I guess the right thing to do is relocate the dynamic stuff via PT_DYNAMIC, and relocate the symtab if its present.

Quoted 3 lines

So I guess the right thing to do is relocate the dynamic stuff via PT_DYNAMIC, and relocate the symtab if its present.

Symtab should also be deduced from program headers.

I'm actually surprised this got re-implemented from scratch, when my patch already had both variants (one just #ifdef-ed out), and was tested in both forms (actually, I first implemented the ELF form, and only after seeing the bloat it added to the sources I came up her than with the second variant, which in the end unfortunately didn't add significantly less bloat to the Makefile.

I have one, too (which is one reasone why I created the original Xen patch).

Quoted 6 lines

Quoted 2 lines

I'm playing safe. Binary identical relocation to 0xffffe000 was my goal.

Yeah, fair enough. But as Eric likes to keep pointing out, an executable ELF file need not have any sections at all, so the only safe course for anything "real" is via the section headers.

Program headers you mean.

Quoted 3 lines

So I guess the right thing to do is relocate the dynamic stuff via PT_DYNAMIC, and relocate the symtab if its present.

Symtab should also be deduced from program headers.

Quoted 1 line

Quoted 1 line

Jeremy Fitzhardinge <[email protected]> 16.03.07 17:46 >>>

Quoted 2 lines · Jan Beulich

I have one, too (which is one reasone why I created the original Xen patch).

It's some version of SuSE 9, right? What glibc version?

Well testing that is not so fun. I installed SUSE Pro 9.0, and strings on ld.so contains the magic at_sysinfo assert! But it doesn't install TLS libraries, so I'll have to install them by hand.

Paravirt-ops guests which move the fixmap also end up moving the syscall VDSO. This fails if it is prelinked at a fixed address, which is why COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN). Several options are available to try to address this. Jan had cooked up a patch for Xen that used build magic to find the parts of the VDSO that need relocation. I don't like the idea of having auto-generated relocations, as someday something could change between two linked objects (timestamp, elf notes perhaps) that is not a relocation. So I prefer human supervision over the relocation and explicitly fixing everything by hand. I'm not necessarily advocating one solution over the other; my way is more code to maintain if the VDSO linkage changes. I'm looking for feedback about which way is best.

Also, it appears that COMPAT_VDSO could disappear entirely. Since this approach should work with older broken ld.so (2.3.2 is the version, I believe), we should be able to switch over completely to using the gate vma style of linking the vdso. One can even get the address randomization benefits by simply running fixup on the vdso if you are prepared to take the cost of allocating an extra page per process. Or you could randomize just once at boot, which makes the randomization per-machine, still sufficient to slow network based worm attacks which might rely on a fixed VDSO address.

Clearly this patch needs more testing and feedback, which I'm sure it will get...

<zach ducks>

Zach

P.S. - Eric, I've copied you as you appear to be an ELF expert, or at least have a greater grasp of Elven Magic than me, and I'm hoping I got all the dynamic tags which need relocation right.
Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled by fixing up the ELF object.

I'm not quite familiar with the context. And I'm to lazy to look right now. What is the difference with COMPAT_VDSO that it doesn't do relocation? What are we preserving?

The practical question here is if we already have all of the relocation logic for the VDSO why do we need to add more?

Quoted 2 lines

The practical question here is if we already have all of the relocation logic for the VDSO why do we need to add more?

The kernel doesn't normally ever relocate the vdso; [...]

that's what is the case right now, but much of the intention behind the vma based vDSO is to enable per-process randomized vdso locations, and various distributions do that. So the 'modern' vDSO concept is very much relocatable.

Quoted 4 lines · Ingo Molnar

that's what is the case right now, but much of the intention behind the vma based vDSO is to enable per-process randomized vdso locations, and various distributions do that. So the 'modern' vDSO concept is very much relocatable.

No, the point is that it never needs relocating. The kernel can map it anywhere and userspace can cope. Its only the broken glibcs which require relocation.

There are three ways of finding the VDSO.
- AT_SYSINFO
- AT_SYSINFO_EHDR
- known fixed address (see x86_64)

Currently it doesn't sound like you need to deal with the known fixed address case but COMPAT_VDSO also provides that.

If userspace uses AT_SYSINFO the premise is that it is not expecting not to need to perform any relocation processing.

If userspace uses AT_SYSINFO_EHDR it expects it needs to perform relocation processing and fixes up whatever needs fixing up.

With the module code we have shown the kernel is capable of performing relocation processing at times and it works.

So is it possible to simply relocate the normal vdso and fixup it's program header so it shows that relocation is not necessary. If you can do that and still export AT_SYSINFO so the problem user space still runs you are good. (If you can relocate the vdso you should be able to relocate it anywhere).

Otherwise it probably just make sense to simply not export a VDSO on those systems.

This would leave COMPAT_VDSO for the case where you must use one magic fixed address, and if user space does not require that it means COMPAT_VDSO could be completely removed.

I'm not quite familiar with the context. And I'm to lazy to look right now. What is the difference with COMPAT_VDSO that it doesn't do relocation? What are we preserving?

The practical question here is if we already have all of the relocation logic for the VDSO why do we need to add more?

I'm tempted to rant on the pure insanity of address space randomization but that is a whole other issue...