headers
Rafal Boni | 13 Apr 2003 00:10
Picon

-current MIPS ld.elf_so fix/workaround

Folks:
	I haven't had a chance to figure out if this is quite the right
	thing or not -- at least from the POV of the specified behaviour,
	but the following small patch makes my ld.elf_so behave correctly
	in the face of the application overriding symbols from shared libs,
	as is done in at least the following places:
		* perl (used during build, the broken ld.elf_so caused the
		  perl build to fall over).
		* bash/tcsh (both define their own free/malloc -- with the
		  -current ld.elf_so, parts of the app use the app-defined
		  malloc/free while other parts use the libc free).

	I'll try and figure out what the right things from a spec POV are
	soon, but at least this gets me up and running (which is the key
	things for me now 8-) again.

	This addresses a bunch of PR's in GNATS as well, so if someone 
	wants to pick this up ASAP, verify that this is indeed correct,
	check it in and close those PR's, I won't complain... I will try
	and get to all that, but probably not in the next week or ten
	days...

	BTW, this is on a system post-binutils-2.13.2.1 update and with
	the stock 2.59.3 gcc.

--rafal

Index: arch/mips/mips_reloc.c
===================================================================
RCS file: /cvsroot/src/libexec/ld.elf_so/arch/mips/mips_reloc.c,v
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christopher SEKIYA | 13 Apr 2003 11:21

Re: -current MIPS ld.elf_so fix/workaround

On Sat, Apr 12, 2003 at 06:10:55PM -0400, Rafal Boni wrote:

> the following small patch makes my ld.elf_so behave correctly

I confirm that this patch makes bash/perl do the right thing.

A couple of comments (aside from the SUPPORT_BROKEN_LD define, which provides
support that might not be necessary anymore):

>  		if (ELF_ST_TYPE(sym->st_info) == STT_FUNC &&
> -		    sym->st_value != 0) {
> +		    *got != sym->st_value) {

This bit I understand ...

> +			 * 
> +			 * XXXrkb: this can't be right?!?
>  			 */
> -			*got = sym->st_value + (Elf_Addr)obj->relocbase;
> +			*got += (Elf_Addr)obj->relocbase;

... this is sort of confusing.  Why does this work, oh holy MIPS gurus?

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)
Permalink | Reply | 1 comment |
headers
Rafal Boni | 13 Apr 2003 18:41
Picon

Re: -current MIPS ld.elf_so fix/workaround

In message <20030413092157.GA29678 <at> rezrov.net>, you write: 

-> On Sat, Apr 12, 2003 at 06:10:55PM -0400, Rafal Boni wrote:
-> 
-> > the following small patch makes my ld.elf_so behave correctly
-> 
-> I confirm that this patch makes bash/perl do the right thing.

Yeah, I tested this with a perl (which didn't even build with the in-tree
ld.elf_so) and tcsh before I sent that email but it is good to have that
seconded 8-)

-> A couple of comments (aside from the SUPPORT_BROKEN_LD define, which 
-> provides support that might not be necessary anymore):

Well, this isn't really true... There's still the "local, section relative"
stuff which gets fixed up by the SUPPORT_BROKEN_LD, and AFAICT, this was
the worse of the two things (in fact, for the case I eliminated, I'm not
sure which binutils versions generate the correct output according to the
comment and which ones don't -- other than the fact that it appears that
the current in-tree one does not).

-> >  		if (ELF_ST_TYPE(sym->st_info) == STT_FUNC &&
-> > -		    sym->st_value != 0) {
-> > +		    *got != sym->st_value) {
-> 
-> This bit I understand ...
-> 
-> > +			 * 
-> > +			 * XXXrkb: this can't be right?!?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rafal Boni | 13 Apr 2003 18:55
Picon

Re: -current MIPS ld.elf_so fix/workaround

In message <200304131642.h3DGfxc21012 <at> fearless-vampire-killer.waterside.net>, 
I had just written:

-> In message <20030413092157.GA29678 <at> rezrov.net>, you write: 
-> 
-> -> On Sat, Apr 12, 2003 at 06:10:55PM -0400, Rafal Boni wrote:
-> -> 
-> -> > the following small patch makes my ld.elf_so behave correctly
-> -> 
-> -> I confirm that this patch makes bash/perl do the right thing.
-> 
-> Yeah, I tested this with a perl (which didn't even build with the in-tree
-> ld.elf_so) and tcsh before I sent that email but it is good to have that
-> seconded 8-)
-> 
-> -> A couple of comments (aside from the SUPPORT_BROKEN_LD define, which 
-> -> provides support that might not be necessary anymore):
-> 
-> Well, this isn't really true... There's still the "local, section relative"
-> stuff which gets fixed up by the SUPPORT_BROKEN_LD, and AFAICT, this was
-> the worse of the two things (in fact, for the case I eliminated, I'm not
-> sure which binutils versions generate the correct output according to the
-> comment and which ones don't -- other than the fact that it appears that
-> the current in-tree one does not).
-> 
-> -> >  		if (ELF_ST_TYPE(sym->st_info) == STT_FUNC &&
-> -> > -		    sym->st_value != 0) {
-> -> > +		    *got != sym->st_value) {
-> -> 
-> -> This bit I understand ...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christopher SEKIYA | 14 Apr 2003 06:40

Re: -current MIPS ld.elf_so fix/workaround

On Sun, Apr 13, 2003 at 12:55:27PM -0400, Rafal Boni wrote:

> I'm not sure which binutils versions generate the correct output according
> to the comment and which ones don't -- other than the fact that it appears
> that the current in-tree one does not).

After a quick test, I agree.  Removing the "broken" conditional (per the first
hunk of your patch) indicates that SUPPORT_OLD_BROKEN_LD should actually
be SUPPORT_NEW_BROKEN_LD :)

> it's never actually hit because it seems that in all the cases I found, the
> GOT value was exactly equal to sym->st_value.

Same here.  I think this bit can be safely omitted.

If this were a democracy, I'd vote to apply the first two parts of the diff.

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)
Permalink | Reply | 1 comment |
headers
Charles M. Hannum | 14 Apr 2003 15:12
Picon

Re: -current MIPS ld.elf_so fix/workaround

On Mon, 2003-04-14 at 04:40, Christopher SEKIYA wrote:
> On Sun, Apr 13, 2003 at 12:55:27PM -0400, Rafal Boni wrote:
> 
> > I'm not sure which binutils versions generate the correct output according
> > to the comment and which ones don't -- other than the fact that it appears
> > that the current in-tree one does not).
> 
> After a quick test, I agree.  Removing the "broken" conditional (per the first
> hunk of your patch) indicates that SUPPORT_OLD_BROKEN_LD should actually
> be SUPPORT_NEW_BROKEN_LD :)

I think y'all need to read the comments in there to understand what's
going on a bit.  That code had the "broken" conditional because it
entirely defeats lazy binding, and so is not very attractive for general
use.

The problem you're running into (which I documented a while back, and
asked for help from some MIPS binutils g00r00s) has to do with the use
of function pointers.  IIRC, function pointers in MIPS executables are
being resolved directly to the function, if the function exists in the
executable, but function pointers in shared libraries are being resolved
to the library's PLT slot.  This is causing the pointers to compare
incorrectly, which in turn causes some random lossage (e.g. libXt
doesn't work so well in some cases).

> > it's never actually hit because it seems that in all the cases I found, the
> > GOT value was exactly equal to sym->st_value.
> 
> Same here.  I think this bit can be safely omitted.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rafal Boni | 14 Apr 2003 19:29
Picon

Re: -current MIPS ld.elf_so fix/workaround

In message <1050325956.17589.63.camel <at> nagasaki.ihack.net>, you write: 

-> On Mon, 2003-04-14 at 04:40, Christopher SEKIYA wrote:
-> > On Sun, Apr 13, 2003 at 12:55:27PM -0400, Rafal Boni wrote:
-> > 
-> > > I'm not sure which binutils versions generate the correct output accordi
-> ng
-> > > to the comment and which ones don't -- other than the fact that it appea
-> rs
-> > > that the current in-tree one does not).
-> > 
-> > After a quick test, I agree.  Removing the "broken" conditional (per the f
-> irst
-> > hunk of your patch) indicates that SUPPORT_OLD_BROKEN_LD should actually
-> > be SUPPORT_NEW_BROKEN_LD :)
-> 
-> I think y'all need to read the comments in there to understand what's
-> going on a bit.  That code had the "broken" conditional because it
-> entirely defeats lazy binding, and so is not very attractive for general
-> use.

Right, I do realize it's defeating lazy binding, but I'd rather have a
runtime linker that works right than one that is fast but doesn't work
correctly 8-)

In the perfect world, all we'd need to do is find a better heuristic to
catch those -- I'm guessing your heuristic for setting "broken" was a
good one to identify old-old libraries which had the problem I found
back in October, 2001 but not so well for identifying the newer issue
of "pointers to functions resolved incorrectly".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 14 Apr 2003 22:33

Re: -current MIPS ld.elf_so fix/workaround

On Sat, Apr 12, 2003 at 06:10:55PM -0400, Rafal Boni wrote:
> Folks:
> 	I haven't had a chance to figure out if this is quite the right
> 	thing or not -- at least from the POV of the specified behaviour,
> 	but the following small patch makes my ld.elf_so behave correctly
> 	in the face of the application overriding symbols from shared libs,
> 	as is done in at least the following places:
> 		* perl (used during build, the broken ld.elf_so caused the
> 		  perl build to fall over).
> 		* bash/tcsh (both define their own free/malloc -- with the
> 		  -current ld.elf_so, parts of the app use the app-defined
> 		  malloc/free while other parts use the libc free).

Just to point, this fixes the problems for me too. No more warning from
tcsh, perl builds, and I restarted the bulk build on my box, which is now
building a buch of packages which depends on perl :)

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--
Permalink | Reply | 0 comments |
headers
HYDRA PR | 15 Apr 2003 20:23

NSA's SPOCK Program Uses HYDRA to Secure its Web site

For Immediate Release:

NSA's SPOCK Program Selects Bodacion's HYDRA Web Server

National Security Agency Deploys Bodacion's Secure Web Technology to Deflect Hackers, Shorten Training
Time and Reduce Maintenance Costs

BARRINGTON, ILLINOIS (April 2, 2003)  The Security Proof of Concept Keystone (SPOCK), a Department of
Defense consortium of corporate and government organizations sponsored by the National Security
Agency (NSA), has selected Bodacion Technologies' HYDRA secure Web Services appliance as its primary
Web server.  The NSA cited HYDRA's extreme resistance to all known hacking attacks, as well as the
appliance's simplicity and reliability, as reasons for choosing Bodacion's product.

"After SPOCK demonstrations showed HYDRA's improved security and maintainability over current
solutions, the NSA saw a clear fit for their own needs," said Eric Ridvan Uner, Co-Founder of Bodacion
Technologies, Co-Inventor of HYDRA and his company's chief liaison to government agencies.  "The NSA, of
course, has a vested interest in making sure that hackers stay out of any NSA Web site, and so the SPOCK
program selected HYDRA for its high level of resistance to hacking attacks of all kinds."

Compatibility and maintenance were also primary SPOCK concerns, according to Uner.  HYDRA was a simple
drop-in replacement for the legacy solution, he said, which required minimal deployment effort.  HYDRA
also will require less maintenance and training than the legacy system, he added.

Last year, SPOCK conducted a demonstration of HYDRA consisting of security claims by Bodacion
Technologies and tests jointly agreed to by the participants.  The results were that all Bodacions
claims were verified.  More than 350 technologists from civil and defense entities are involved in the
SPOCK program; currently there are 65 security-related corporations and 19 government agencies
participating in the program. 

Bodacions appliance is designed specifically for secure Web Services computing and has captured the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iggy Drougge | 21 Apr 2003 14:13
Picon

Port suggestion: NEC EWS 4800 series

I think I've mentioned this range of machines previously, but now I've
managed to dig up some more information.
This is a series of UNIX workstations produced by NEC since (I think
the eighties). Seemingly following Sony NEWS in every move, they
started out as m68k machines, later crossing over to MIPS. NEC's own
pages seem to suggest that they are even still being sold. They run a
UNIX variant called UX/4800 (formerly EWS-UX, with UP-UX for the
server models).
Buses are all over the place, with VME, AP-bus (this is a NEWS thing
too, isn't it?), and EISA and PCI on the later models. The current
models use NEC-made R12000 and R14000 processors, some in
multiprocessor configurations, I think (at least this was the case in
certain R4400 and R10000 models).
Here is an overview of the series: 
http://www.nishimoto-site.net/archiver/fj/unix/200209/msg00016.html

It seems that Izumi Tsutsui owns half a dozen of EWSes, perhaps he
could shed some light on their viability as NetBSD targets, if he's
reading this?

--

-- 
En ligne avec IMHO webmail v0.98.2

Amiga 4000 25MHz/64MO/20GO/FastlaneZ3/RetinaBLTZ3/Ariadne
HP Visualize C180
Tatung SuperCOMPstation 20S
SUN Sparcstation 10
DECstation 5000/200
(Continue reading)

Permalink | Reply | 0 comments |

Gmane