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

[Eric W. Biederman]

Zachary Amsden <zach@xxxxxxxxxx> writes:

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

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

Eric
-
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/