Re: cvs commit: src/contrib/gcc protector.c protector.h Makefile.in calls.c combine.c cse.c explow.c expr.c flags.h function.c gcse.c integrate.c libgcc2.c loop.c optabs.c reload1.c toplev.c src/gnu/usr.bin/cc/cc_int Makefile

[Max Laier <max@xxxxxxxxxxxxxx>]

Richard Coleman wrote:
> Matthew Dillon wrote:
>
> >     I don't know who comes up with these names.  W^X?  IA32 does not 
> > support
> >     fine-grained permissions, the only way to make the stack 
> > non-executable
> >     is to modify the SS segment register and while this does work, it 
> > creates
> >     severe restrictions on how threaded programs can operate.
> >                          -Matt
> >                     Matthew Dillon                     
> > <dillon@xxxxxxxxxxxxx>
>
>
>
> Yes, but OpenBSD supports other archs besides IA32.  I think it was IA32 
> and PowerPC that didn't have the bits necessary to do W^X properly.  So 
> the OpenBSD folks did the best they could with the bits that were 
> provided.  I think it's pretty exciting stuff.

from http://www.openbsd.org/papers/csw03.mgp:
>> i386 PROT_EXEC best-effort
>>
>> i386 lacks per-page X bit
>>
>> Only significant relevant hardware feature:
>> 	code segment limit
>> 	3.2/3.3: points below bottom of stack -> no-exec stack
>>
>> Link each shared object to have 1GB gap between code & data
>>
>> Map all text segments low, all data segments 1GB higher
>>
>> Set code segment limit register to point up to highest PROT_EXEC page
>> 	(floating CS limit)
>> 	Normally somewhere below 1GB
>>
>> Will be in 3.4: W^X on i386
>>
>> Changing CS limit is a bit expensive: slight overhead

--
Best regards,				| max@xxxxxxxxxxxxxx
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier@EFnet #DragonFlyBSD