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,
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
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
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
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
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
* 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
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
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
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
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,
>>> 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.
>>
>>
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
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 works - in
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,
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 to
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 address,
* 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 intention
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
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 pointing
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 unsubscribe
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
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
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-bit
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,
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
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
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
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:
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
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
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:
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
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 produce
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
36 matches
Mail list logo
