On Thu, 2005-01-06 at 02:28 +0100, pageexec@freemail.hu 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 a new ELF program header type called PT_PAX_FLAGS and requires a binutils patch (being specific to PaX and in direct conflict with PT_GNU_STACK, it has about 0 chance to end up upstream).
Hmm, OK. If you think PaX may be deployed in a mainstream distribution like Ubuntu by default being able to build with this marking is something we should remember.
my problem wasn't that you reserved all address space 'upstairs', but that the algo wine has can end up in an infinite loop (requesting kernel space memory is another thing, but given how non-existant is a decent API for learning about the address space layout in linux, i won't blame this on you ;-).
Yeah, scraping /proc/self files is silly but unfortunately quite common on Linux ... I'd love a decent VirtualQuery type API for other non-Wine stuff I've done if nothing else.
interestingly, i also have this need to have some control over the address space and have a plan to do this eventually. the idea is to introduce a new ELF program header (because this is the easiest to parse at execve() time in the kernel), that would describe the desired TASK_SIZE, stack placement and other info you might need. how something like this would fly with upstream (both binutils and the kernel), i can't tell however.
That would be good. My last experience with this sort of patch was trying to fix a bug in the kernel ELF loader though. John Reiser developed a patch which fixed the bug but it didn't compile on some architecture he didn't have access to and was dropped.
you're right with the behaviour of MAP_FIXED, but then i still think that something is wrong with the allocation algo if it can loop forever (or i wasn't patient enough).
That's something for Alexandre to comment on, I didn't write that code and never really looked at it.
if you need more info, feel free to ask. for your particular question, it's always been about the compiler detecting the use of nested function trampolines (never inline asm and other ways of runtime code generation) and the linker erring on the side of backwards compatibility.
OK. For your other email I think it'd be better to use the gas pseudo-op to add the .note.GNU-stack, that way we don't need configure checks for the ld flags.
ok, this is the really interesting part for me, so let's discuss it a bit more.
a) Used by some Windows programs
this is fine and can't be helped of course. my hope is that most apps, or rather, the ones i'm personally interested in don't generate code runtime.
b) Used by the Wine DLL loader
what is this use exactly? can it be reworked to not require runtime code generation (remember that i'm willing to scratch my own itch, i just need some pointers)?
Alexandre recently added a patch to generate DLL stubs at runtime as part of the process of removing them from the compile-time generated code. I think it's also used for +relay traces (where each API call is dumped as it's called).
Obviously +relay is only used in debugging so Wine could run without that. The stub block thing is a bit trickier, that patch could be reversed and Wine would still run correctly because we still generate stubs at compile-time too (iirc), but it's part of a policy of eliminating unnecessary stubs over time. So I'm not sure Alexandre would want to remove it.
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/typelib marshaller proxy is a COM interface (so an array of function pointers) that when called marshal the arguments into a packet and dispatch it via the Windows RPC infrastructure. These proxies come in three forms:
- precompiled MIDL/C marshallers - precompiled MOPs (these are a custom bytecode language fed to a VM which does the marshalling) - generated at runtime from type libraries (databases which describe the types and interfaces used in a program)
I don't know if the second needs runtime code geneation but I don't see any way we can avoid generating code for the third at runtime.
and same question as above of course. also, this feature doesn't sound like something that all windows apps need,
I'm afraid InstallShield needs it, and InstallShield is a "gateway" app, ie if it doesn't run lots of other programs also don't run (because you can't install them).
so i wouldn't have a problem with allowing it (note that i'm talking about PaX based systems only, not wine in general, so no worries about me trying to force something on you) if i can run the rest of the apps with full PaX enabled.
Yes the trick is, how do you know when it's needed or not? I'm not sure.
i've never sad it wasn't legitimate, just that it's a privilege and if we want protection from exploits, then we'd better revoke it from apps that don't need it (and which get it by default and cause security problems).
OK this opinion is fair enough, if a little unusual.
obviously my goal is to run as many apps as possible without this privilege (especially those that process untrusted user input, be that server daemons or client apps like mail clients, web browsers, etc). if there're fundamental reasons why wine cannot work without such a privilege, then so be it, it'll go the way of java on PaX systems and be exempted.
I think some programs could run on a hacked and Wine but the problem is when InstallShield fails in a mysterious way how do you know it's PaX and not some other problem? I don't see how to communicate that to the user in a useful manner ...
They have to be fixed otherwise the kernel may place them in the middle of a reserved area which would cause initialisation to fail. This cannot be changed.
i meant something like a new switch to configure that would let you specify a new compile/link time base address, that can surely be arranged...
Ah yes that could work though you'd have to test the resulting binaries to ensure there were no conflicts (the reserved regions are stored in a table).
there's already such support in the binutils patch i mentioned above: 'ld -z execheap/-z noexecheap' (you'd use the former to mark the preloader which in turn would allow runtime code generation). post linking, you can use 'paxctl -spmr' (or the deprecated chpax) to disable all non-exec enforcement and randomization. but as i suggested at the beginning, this should not be your concern but that of the distro guys (and pending the questions i raised, it may very well turn out to be unnecessary, at least i'll try my best to make it happen).
OK, thanks for the feedback. I have to admit I'm not keen on leaving much up to the distribution guys, in the past they've typically shown little to no concern about keeping Wine working (probably because due to our ridiculously fast release cycle we're never shipped as part of their base sets).
thanks -mike