On Mar 15 2007 20:03, Zachary Amsden wrote:
> 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.
9.0 is kinda old. And if you want some TLS libs, in
ebiederm wrote:
> I'm tempted to rant on the pure insanity of address space randomization
> but that is a whole other issue...
Please do rant; all I can see asr brings is one big performance hit.
Of course, it's not enough to just attack this at the kernel, but glibc has
to play accordingly as w
Eric W. Biederman wrote:
> 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.
>
Yes, I don't think any 32-b
Eric W. Biederman wrote:
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?
COMPAT_VDSO causes the link address to be fixed at compile time to match
the virtual address o
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Ingo Molnar wrote:
>> 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
>
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 16.03.07 17:46 >>>
>Jan Beulich wrote:
>> 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?
Yes. 2.3.2.
Jan
-
To unsubscribe from this list: send the line "unsu
Jan Beulich wrote:
> 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?
>>> I'm playing safe. Binary identical relocation to 0xe000 was my goal.
>>>
>> Yeah, fair enough. But as Eric likes to keep
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > 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 inten
Ingo Molnar wrote:
> 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 re
Eric W. Biederman wrote:
> 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 issue is that with COMPAT_VDSO, the vdso gets mapped at two places:
one random addre
Zachary Amsden <[EMAIL PROTECTED]> 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
Jan Beulich wrote:
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.
Learning more all the time..
I'm actually surprised this got re-implemented from scratch, whe
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 16.03.07 06:10 >>>
>Zachary Amsden wrote:
>> 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
Jeremy Fitzhardinge wrote:
+} 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
Zachary Amsden wrote:
> 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 prod
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 SU
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?
> Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
>
> Index: linux-2.6.21/arch/i386
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 fo
18 matches
Mail list logo
