Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

From: Zachary Amsden
Date: Fri Mar 16 2007 - 00:03:42 EST


Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
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?

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.

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

Will do.

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...

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

+ } 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.

Walk based on size instead?

+ } 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.

Hmm, I can try that. Thanks for the suggestions / fixes.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/