RFC: Disallow protected data symbol with copy relocation?

RFC: Disallow protected data symbol with copy relocation?

[H. J. Lu]

Protected data symbol with copy relocation never works as intended.
The problem is with copy relocation, main and DSO see different
copies of the protected data symbol. Updating one won't change
the other. You can't compare their addresses either. There is no
easy way to get it to work unless the psABI is changed. I am proposing
to make linker to reject protected data symbol with copy relocation.
Any comments?


H.J.

Re: RFC: Disallow protected data symbol with copy relocation?

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> Protected data symbol with copy relocation never works as intended.
> The problem is with copy relocation, main and DSO see different
> copies of the protected data symbol. Updating one won't change
> the other. You can't compare their addresses either. There is no
> easy way to get it to work unless the psABI is changed. I am proposing
> to make linker to reject protected data symbol with copy relocation.
> Any comments?

Why would the linker ever generate a copy relocation for a protected
symbol?  I don't see how that makes sense.

Ian

Re: RFC: Disallow protected data symbol with copy relocation?

[H. J. Lu]

On Fri, Jan 21, 2005 at 12:07:01AM -0500, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > Protected data symbol with copy relocation never works as intended.
> > The problem is with copy relocation, main and DSO see different
> > copies of the protected data symbol. Updating one won't change
> > the other. You can't compare their addresses either. There is no
> > easy way to get it to work unless the psABI is changed. I am proposing
> > to make linker to reject protected data symbol with copy relocation.
> > Any comments?
> 
> Why would the linker ever generate a copy relocation for a protected
> symbol?  I don't see how that makes sense.
> 

For some psABIs, copy relocation is the normal way for main to access
data symbol on DSO. On ia32, you may generate writable text section
to work around it or compile main with PIC to avoid copy relocation.
But on x86_64, you may have to compile main with PIC.


H.J.

Re: RFC: Disallow protected data symbol with copy relocation?

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> > Why would the linker ever generate a copy relocation for a protected
> > symbol?  I don't see how that makes sense.
> > 
> 
> For some psABIs, copy relocation is the normal way for main to access
> data symbol on DSO.
> ...

Yes, I know.  But clearly a copy relocation can not work.  We should
treat this case as though -z nocopyreloc was used for that specific
symbol.

Maybe that is what you meant by "reject protected data symbol with
copy relocation."  I am saying that the answer is not to reject the
symbol, it is to not generate the copy relocation.

There may be specific targets and/or cases where -z nocopyreloc does
not work, for some hideous reason.  Those specific targets and/or
cases should generate a specific error.  But this is not a general
problem.

Ian

Re: RFC: Disallow protected data symbol with copy relocation?

[H. J. Lu]

On Fri, Jan 21, 2005 at 12:46:26AM -0500, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > > Why would the linker ever generate a copy relocation for a protected
> > > symbol?  I don't see how that makes sense.
> > > 
> > 
> > For some psABIs, copy relocation is the normal way for main to access
> > data symbol on DSO.
> > ...
> 
> Yes, I know.  But clearly a copy relocation can not work.  We should
> treat this case as though -z nocopyreloc was used for that specific
> symbol.
> 
> Maybe that is what you meant by "reject protected data symbol with
> copy relocation."  I am saying that the answer is not to reject the
> symbol, it is to not generate the copy relocation.

Avoid copy relocation leads to writable text section on ia32. I am not
sure that generate writable text section without -z nocopyreloc is a
good idea.

> 
> There may be specific targets and/or cases where -z nocopyreloc does
> not work, for some hideous reason.  Those specific targets and/or
> cases should generate a specific error.  But this is not a general
> problem.

I don't think -z nocopyreloc works on x86_64.


H.J.

Re: RFC: Disallow protected data symbol with copy relocation?

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> Avoid copy relocation leads to writable text section on ia32. I am not
> sure that generate writable text section without -z nocopyreloc is a
> good idea.

I don't see why it is better to prevent the user from generating an
executable at all.

What this is really leading up to is that it is unwise for a shared
library to declare a global variable to be protected.  Doing that
makes it costly for the main executable to refer to that global
variable.

But if a shared library does declare a global variable to be
protected, and if the main executable does refer to it, I think we
should attempt to support that.  I don't see why we should simply
reject it and make it impossible to use the shared library in that
way.  We could perhaps issue a warning in that case.

> I don't think -z nocopyreloc works on x86_64.

Can it be fixed, or is there some reason that it is impossible?

Ian

Re: RFC: Disallow protected data symbol with copy relocation?

[H. J. Lu]

On Fri, Jan 21, 2005 at 01:26:06AM -0500, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > Avoid copy relocation leads to writable text section on ia32. I am not
> > sure that generate writable text section without -z nocopyreloc is a
> > good idea.
> 
> I don't see why it is better to prevent the user from generating an
> executable at all.
> 
> What this is really leading up to is that it is unwise for a shared
> library to declare a global variable to be protected.  Doing that
> makes it costly for the main executable to refer to that global
> variable.
> 
> But if a shared library does declare a global variable to be
> protected, and if the main executable does refer to it, I think we
> should attempt to support that.  I don't see why we should simply
> reject it and make it impossible to use the shared library in that
> way.  We could perhaps issue a warning in that case.

I see. For ia32, we can issue a warning when generating such a shared
library and generate writable text section when it is referenced by
main executable.


> 
> > I don't think -z nocopyreloc works on x86_64.
> 
> Can it be fixed, or is there some reason that it is impossible?
> 

I think it has something to do with the psABI and Linux runtime,
something like relocation is 32bit and main/DSO are several GB
apart. For x86_64, we can warn it when creating such a shared
library and refuse to link if it is referenced by main.


H.J.

RFC: Properly handle protected data symbol with copy relocation

[H. J. Lu]

On Thu, Jan 20, 2005 at 10:45:13PM -0800, H. J. Lu wrote:
> On Fri, Jan 21, 2005 at 01:26:06AM -0500, Ian Lance Taylor wrote:
> > "H. J. Lu" <hjl@lucon.org> writes:
> > 
> > > Avoid copy relocation leads to writable text section on ia32. I am not
> > > sure that generate writable text section without -z nocopyreloc is a
> > > good idea.
> > 
> > I don't see why it is better to prevent the user from generating an
> > executable at all.
> > 
> > What this is really leading up to is that it is unwise for a shared
> > library to declare a global variable to be protected.  Doing that
> > makes it costly for the main executable to refer to that global
> > variable.
> > 
> > But if a shared library does declare a global variable to be
> > protected, and if the main executable does refer to it, I think we
> > should attempt to support that.  I don't see why we should simply
> > reject it and make it impossible to use the shared library in that
> > way.  We could perhaps issue a warning in that case.
> 
> I see. For ia32, we can issue a warning when generating such a shared
> library and generate writable text section when it is referenced by
> main executable.
> 
> 
> > 
> > > I don't think -z nocopyreloc works on x86_64.
> > 
> > Can it be fixed, or is there some reason that it is impossible?
> > 
> 
> I think it has something to do with the psABI and Linux runtime,
> something like relocation is 32bit and main/DSO are several GB
> apart. For x86_64, we can warn it when creating such a shared
> library and refuse to link if it is referenced by main.
> 

This is my proposal.


H.J.
-----
There is a problem on ia32 and x86_64, where copy relocation is
used to allow main executable to access data variables in DSO.
Normally, linker will create a copy relocation when main references a
data variable in DSO. At the runtime, dynamic linker will create a copy
of the data variable from DSO to the address space of main. It will
arrange both DSO and main to access the copy in main instead of the
original one in DSO. When a data variable in DSO is marked protected,
DSO will always use the original one it has and main will use the copy.
Now, main and DSO will see 2 different ones even though the one in main
is just a copy of the original one.

I am proposing

1. For ia32, when creating a shared library with a protected data
variable, we warn that the resulting DSO will lead to main executable
to be compiled with PIC or be generated with writable text section when
the data variable is accessed. Linker will issue a warning when a main
executable is made with writable text section because of it.
2. For x86_64, when creating a shared library a protected data
variable, we warn that the resulting DSO will lead to main executable
to be compiled with PIC when the data variable is referenced. Linker
will issue an error when a main executable references a protected data
symbol with R_X86_64_PC32 since main and DSO may be more than 2GB
apart.

Re: RFC: Properly handle protected data symbol with copy relocation

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> I am proposing
> 
> 1. For ia32, when creating a shared library with a protected data
> variable, we warn that the resulting DSO will lead to main executable
> to be compiled with PIC or be generated with writable text section when
> the data variable is accessed. Linker will issue a warning when a main
> executable is made with writable text section because of it.
> 2. For x86_64, when creating a shared library a protected data
> variable, we warn that the resulting DSO will lead to main executable
> to be compiled with PIC when the data variable is referenced. Linker
> will issue an error when a main executable references a protected data
> symbol with R_X86_64_PC32 since main and DSO may be more than 2GB
> apart.

Seems more or less reasonable.  I still don't understand why x86_64
can't simply use a writable text section.  I understand that it
doesn't do it; I don't understand why it can't do it.

Ian

Re: RFC: Properly handle protected data symbol with copy relocation

[Alan Modra]

On Mon, Jan 24, 2005 at 02:47:50PM -0500, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> Seems more or less reasonable.  I still don't understand why x86_64
> can't simply use a writable text section.  I understand that it
> doesn't do it; I don't understand why it can't do it.

The problem is that x86_64 uses a 64-bit address space, so 32-bit
pc-relative relocations in the executable may not be able to reach into
a shared library.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre