This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][MIPS] Add linker emulation for N64 ABI with forced 32-bit symbols


David Daney <ddaney.cavm@gmail.com> writes:
> On 11/15/2012 02:22 PM, Paul_Koning@Dell.com wrote:
>> The interesting case is where a program executes without immediately
>> crashing, but because it uses 32-bit addresses it does some wrong
>> things -- writing wrong data into a database, or things like that.  So
>> this isn't a case of lecturing, it's a security improvement.
>>
>
> I think this is a real issue.  Imagine a program larger than 2GB, any 
> relocations against symbols beyond the 2GB boundary, are silently 
> truncated.  The resulting erroneous addresses could easily be pointing 
> into validly mapped parts of the program image.

Well, for accesses that take advantage of -msym32, addresses in the
[2GB, 4GB) range would be sign-extended and transform into kernel addresses.
I think that's likely to be noticed :-)

I agree it would still be a nice feature to have.  But I think it's a
separate issue from what the start address should be.  A related feature
would be to reject PIC objects in which the GOT is over 2GB from the
start of the text section (or at least the first GP load).  At the
moment the GP loads would be mishandled too.  E.g.:

	.globl	foo
	.ent	foo
foo:
	lui	$4,%hi(%neg(%gp_rel(foo)))
	daddu	$4,$4,$25
	daddiu	$4,$4,%lo(%neg(%gp_rel(foo)))
	.space	1 << 31
	.end 	foo

links without error with "-shared -fPIC", but foo computes a negative
offset from $25.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]