Re: versioning of _Unwind_*() symbols

["H. J. Lu" <hjl at lucon dot org>]

On Thu, Apr 22, 2004 at 10:38:35AM -0700, Mark Mitchell wrote:
> H. J. Lu wrote:
> 
> >>>     
> >>>
> >>I don't necessarily see that as a good idea.  If, for example, "operator 
> >>new" were to be broken, then old binaries that use the broken version 
> >>might crash sometimes.  Providing a fixed version of "operator new" 
> >>would help those binaries, not hurt them.  There might be some other old 
> >>   
> >>
> >
> >I was not talking about those binaries.
> > 
> >
> You can't know which binaries you'd affect.  If you fix an 
> implementation bug in an existing function, without changing the 
> version, you'll help some binaries and you may hurt others.
> 
> In my opinion, it makes sense to have the change affect all binaries.
> 
> These functions are very fundamental.  They're like "strlen".  If we 
> found a bug in "strlen", would fixing it in libc result in changing the 
> version number of that symbol? 
> 
> In fact, if you discover a bug in these ABI functions, you are likely to 
> have uncovered a security bug.  It's quite possible that a program which 
> gets an incorrect answer from an ABI function will do something it 
> should not.  If you version the symbol, then fixing the bug will not fix 
> the security bug.  You will have to go recompile all the programs on the 
> system that use the ABI function in order to get the fix.
> 

Your example shows how versioning will help here. If the existing
programs can't pass the security audit without recompiling after
fixing the ABI implemenation, we can change the version without
providing the old version for backward compatibilty, those programs
won't post a security risk since they can't run. Or we can put
a warning message in the old version if the risk is relatively low.

Without versioning, it won't be easy to fix the security bug in the
implemenation.


H.J.