All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Virtualization Mailing List <virtualization@lists.osdl.org>,
	Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jan Beulich <jbeulich@novell.com>
Subject: Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT
Date: Thu, 15 Mar 2007 20:03:10 -0800	[thread overview]
Message-ID: <45FA16FE.7010805@vmware.com> (raw)
In-Reply-To: <45FA0D13.6080601@goop.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Zachary Amsden <zach@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Jan Beulich <jbeulich@novell.com>,
	Rusty Russell <rusty@rustcorp.com.au>, Andi Kleen <ak@suse.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT
Date: Thu, 15 Mar 2007 20:03:10 -0800	[thread overview]
Message-ID: <45FA16FE.7010805@vmware.com> (raw)
In-Reply-To: <45FA0D13.6080601@goop.org>

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

  reply	other threads:[~2007-03-16  4:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-16  2:47 [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT Zachary Amsden
2007-03-16  3:20 ` Jeremy Fitzhardinge
2007-03-16  3:20   ` Jeremy Fitzhardinge
2007-03-16  4:03   ` Zachary Amsden [this message]
2007-03-16  4:03     ` Zachary Amsden
2007-03-16  5:10     ` Jeremy Fitzhardinge
2007-03-16  5:58       ` Zachary Amsden
2007-03-16  5:58         ` Zachary Amsden
2007-03-16  8:08       ` Jan Beulich
2007-03-16  8:41         ` Zachary Amsden
2007-03-16 16:46         ` Jeremy Fitzhardinge
2007-03-16 17:09           ` Jan Beulich
2007-03-16 23:09     ` Jan Engelhardt
2007-03-16 11:56 ` Eric W. Biederman
2007-03-16 11:56   ` Eric W. Biederman
2007-03-16 16:25   ` Jeremy Fitzhardinge
2007-03-16 16:25     ` Jeremy Fitzhardinge
2007-03-16 16:31     ` Ingo Molnar
2007-03-16 16:33       ` Jeremy Fitzhardinge
2007-03-16 16:33         ` Jeremy Fitzhardinge
2007-03-16 19:06         ` Eric W. Biederman
2007-03-16 19:06           ` Eric W. Biederman
2007-03-16 19:46           ` Jeremy Fitzhardinge
2007-03-16 19:38   ` Zachary Amsden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45FA16FE.7010805@vmware.com \
    --to=zach@vmware.com \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=ebiederm@xmission.com \
    --cc=jbeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.