Re: [Fwd: [gentoo-security] pax and objc]

[pageexec]

> I also have a report from a user using gcc-3.3.3 (on gentoo) that 
> installing libffi, and not ffcall, let his by-hand GNUstep install 
> work, whereas ffcall would trigger PaX.  Likely, this is because of 
> mprotect() use in ffcall.  However, ffcall, according to Lv on 
> #gentoo-dev, isn't 64-bit safe, so libffi should probably e used 
> dominantly at the moment, anyway.

if libffi can accomplish the same things as ffcall but without
runtime code generation, then my preference would also be the
former, from a security point of view.

> Uhmm.  I think this is the first honest case of "it's a feature, not a 
> bug" that I've ever seen.  I haven't looked at the libobjc source in 
> gcc, ever, but I'm going to take an educated guess and say that I 
> believe the runtime generation of code allows it to do run-time 
> introspection and execution that simply isn't possible to create a 
> structure for at compile time.  Objective-C is a compiled language, 
> but retains a lot of it's SmallTalk inspired design.

what i saw in the sources of ffcall seems to be small snippets of
asm code called trampolines (similar in nature to the infamous
gcc nested function trampolines), which in turn also means that
if i was hard pressed i could add emulation into PaX (like we have
it for the gcc nested function ones), but i'd rather not go down
that slippery slope...

> Having said all this, AFAIK, libffi (giving up on ffcall at the 
> moment) is the spot where trouble with security features like PaX is 
> going to exist.  If this is the case, is there anyone out there that 
> can confirm or deny this?

i took a brief look at libffi and found no obvious signs of runtime
code generation so i think it'll be ok with PaX. if not, we'll know
soon enough ;-). now if obj-c itself does something then it's a
different situation, only the previously mentioned workarounds will
help.