On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Arjan van de Ven wrote: > >>>Hmmmm you either need an executable stack or you don't. Can you explain > >>>why you think there is a strong advantage for a "neutral" setting on > >>>this one? > >>> > >> > >>As I said, compatibility mode. The toolchain should not emit > >>*everything* PT_GNU_STACK and leave it up to you to de-mark it; instead, > >>everything should be emitted without PT_GNU_STACK set, in which case > >>violating code would die. > > > > > > actually right now the toolchain marks things automatically correct. > > If gcc emits a stack trampoline, it gets marked needing executable > > stack, if gcc can prove it doesn't need executable stack, it gets marked > > as such as well. > > > > And the toolchain emits a -E library with PT_PAX_FLAGS if there's a > stack trampoline :) But it's defficient right now, doesn't inherit when > you link to a library with -E. . . you can fix that right? :)
it's inherited for PT_GNU_STACK though. Not sure how you implemented PT_PAX_FLAGS, but for PT_GNU_STACK it's inherited. > > I *really* don't understand why you want to get away from automatic > > marking to something manual, which *has* to be more fragile. > > > > /me shrugs. It's a security blanket for him mostly; he fears automagic > security maintainence. who is "him" ? > > > > >>Remember also I'm very much against "let the compiler guess if you need > >>an executable stack" > > > > > > it's not guessing. the *compiler* emits the stack trampoline. So the > > *compiler* knows that it needs that stack. > > > > With a trampoline, things like Grub and a few libs need PT_GNU_STACK. sure they do. There's about a handful in an entire distro. > > Of course you can't just suddenly say "OH! Well PT_GNU_STACK should do > this instead!" because you'll break everything. I'm not a fan of any kind of emutrampoline. At all. But I am open to others making a different tradeoff; for me the option to have a trampoline at all is just a bypass of the non-exec stack... legit bypass one hopes but a bypass regardless. Some time ago we did an eval of how much stuff would need the emutramp (well or something equivalent) and the list was so small that I decided that the added risk and complexity were not worth it and that I rather had those 5 or so apps run with exec stack. > > again what does tristate mean.. "I don't know" ? But gcc does know, with > > very very very few exceptions. Eg old mono is the exception because it > > didn't do a proper mprotect. Saying "I don't know" doesn't solve you > > anything, since in the end there needs to be a policy enforced anyway, > > it's just postponing the inevitable to a point with less knowledge. > > > > Remember I'm also thinking of restricted mprotect() situations as well, > because I'm trying to get it to the point where one set of markings has > a predictable effect on any kernel, be it vanilla, pax, or ES. well that is an entirely independent thing again. Really. I think mixing all these into one big flag is a mistake. (And thats a lesson I learned the hard way, but Linus was right; don't mix independent things into one flag artificially. Extra flags are cheap. Don't complicate the world for a dozen bytes.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
