> This can't do everything. It protects against return-to-libc style
> attacks but there are other stack based attacks that it doesn't work for
> (if I remember correctly).
I.e. for C++ apps you could instead change the implicit this argument of the
caller, for example, to point to a made-up inst
> Actually, we shouldn't be generating assembly code on the fly. If you
> have more than say 16 proxies in a process then it is actually cheaper
> in terms of memory usage and cache locality to have a set of compiled
> entry points that can be shared by all proxies. It is even better if you
> c
On Fri, 2005-01-07 at 13:46 +0100, [EMAIL PROTECTED] wrote:
> i totally agree with you on this one ;-), but the feasibility of this
> depends on how dynamic these proxies have to be, i.e., is enough
> information known at compile/link time to create them in a read-only
> section or not.
The thunks
On Thu, 2005-01-06 at 15:47 -0600, Robert Shearman wrote:
> Actually, we shouldn't be generating assembly code on the fly. If you
> have more than say 16 proxies in a process then it is actually cheaper
> in terms of memory usage and cache locality to have a set of compiled
> entry points that c
Mike Hearn wrote:
On Thu, 2005-01-06 at 02:28 +0100, [EMAIL PROTECTED] wrote:
c) Required to implement DCOM universal interface proxies
required as in 'cannot be implemented any other way'?
I'm not sure. These proxies are run-time generated objects. Essentially
a DCOM universal/type
> http://source.winehq.org/source/dlls/ntdll/
>
> It's fairly harmless, there is some assembly in there but I don't
> remember seeing any code which assumed an executable stack.
i've looked at it and as i suggested yesterday, it's a false positive.
what happens here is that relay32.s doesn't emit
On Thu, 2005-01-06 at 02:28 +0100, [EMAIL PROTECTED] wrote:
> for historical reasons, there're 2 marks. the older one (controlled by
> chpax) abuses an otherwise (or yet) unused field in the ELF header, i
> personally don't encourage the use of it. the other one (controlled by
> paxctl) is based on
> Thanks for the great info. I'll CC this to wine-devel as I think it's of
> general interest, I hope you don't mind.
sure, no problem (let's hope i don't bounce by not being subscribed ;-).
> http://lists.debian.org/debian-devel/2003/11/msg00206.html
>
> in which the PaX author and Ingo Molnar
Hi,
Thanks for the great info. I'll CC this to wine-devel as I think it's of
general interest, I hope you don't mind.
For context, PaX is a set of security patches for Linux which lock down
the system in a similar manner to exec-shield and SELinux. I say similar
manner, because PaX seems to go fu
