> > [...] also, you did break userland yourself as well, otherwise how would > > you explain the patches RedHat made to the XFree86 server? > > actually, unmodified XFree86 works just fine. It will have an executable > stack but it will work out of box - so no app was broken.
false! my unmodified X server (gentoo) dies with the following core when trying to run it under [1]: (gdb) bt #0 0x00caf471 in kill () from /lib/libc.so.6 #1 0x00caf215 in raise () from /lib/libc.so.6 #2 0x00cb07bb in abort () from /lib/libc.so.6 #3 0x0806eb99 in AbortDDX () #4 0x080ed43a in FatalError () #5 0x0808522c in xf86SigHandler () #6 <signal handler called> #7 0x0a226000 in ?? () #8 0x080a6f98 in LoadModule () #9 0x0806fa3c in xf86LoadModules () #10 0x0806db2a in InitOutput () #11 0x080d36c1 in main () does LoadModule() ring a bell? why don't you realize that there's a world beyond RedHat and that you *do* break those people's system? heck, you did break RedHat users' systems as well, you say so yourself: [2] or [3]. every time you suggest that a user upgrade X means that you have broken his existing binary - a clear no-no by your own rules. > X does break if you force exec-shield=2, and it did break even with > exec-shield=1 in earlier iterations of exec-shield, but that bug has been > fixed. excerpt from [1]: --- linux/kernel/sysctl.c.orig +++ linux/kernel/sysctl.c @@ -52,6 +52,9 @@ extern int core_uses_pid; extern char core_pattern[]; extern int cad_pid; +int exec_shield = 2; +int exec_shield_randomize = 1; that to me means that *everyone* will have his *existing* binary broken, by your own admission. it also means that you have violated the very rule of Linus you had referred to before. > the XFree86 patching you refer to above we did was to enable non-exec > stack. But this was an iterative thing to enhance security, not something > we had to do because X broke due to exec-shield itself. XFree86 never needed an executable stack as far as i know, what was there to 'enhance' then? it is clear that XFree86 did break because of Exec-Shield and you had to modify both to get it to work and be able to claim that it works out of the box. incidentally, if i were to make use of PT_GNU_STACK in PaX, i could claim the same - now what was your point of fighting this silly issue? by the way, on another look at your patch i noticed the following: 1. you added a new parameter to fs/binfmt_elf.c:create_elf_tables() but don't make use of it, probably it's not needed at all now. 2. in fs/exec.c:setup_arg_pages() you may create an inconsistent state between mpnt->vm_page_prot and mpnt->vm_flags, the former should be derived from the latter, just like do_mmap_pgoff() does it. [1] http://people.redhat.com/mingo/exec-shield/exec-shield-2.4.22-G4 [2] http://marc.theaimsgroup.com/?l=linux-kernel&m=106482772021534&w=2 [3] http://marc.theaimsgroup.com/?l=linux-kernel&m=106502603232695&w=2