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.)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
[...]
>>/me shrugs. It's a security blanket for him mostly; he fears automagic
>>security maintainence.
>
>
> who is "him" ?
>
me in third person? :)
>
>>>>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.
Right, so it's a toss-up: Do you want to fix these few things, or do
you want to let trampolines exist? Are trampolines that useful?
>
>
>>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.
>
Eh.
>
>>>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.)
>
>
two or four dozen bytes, eight dozen bytes in 10 years when 128 bit
systems come along, and 16i dozen planck qubytes when we get quantum
computers :)
Actually when I proposed adding PT_PAX_FLAGS to Ubuntu, the very first
argument I got was "Oh, yeah right, add just a few bytes here for this.
Then later it'll be a few more bytes for something else. Then a few
more for another thing. It all adds up, especially when you have
thousands of binaries."
And if bitfield logic is "complicated," you should stop pretending to be
a programmer.
#define BIG (1)
#define LONG (1 << 1)
#define FAT (1 << 2)
#define TALL (1 << 3)
#define GREEN (1 << 4)
struct foo {
char *myname;
unsigned long flags;
};
struct foo *newfoo() {
struct foo *out = malloc(sizeof(struct foo));
out->myname = malloc(4);
strcpy(out->myname, "bob");
out->flags = BIG | TALL | GREEN;
return out;
}
Easy enough?
struct foo {
char myname[10];
int big;
int long;
int fat;
int tall;
int green;
};
struct foo *newfoo() {
struct foo *out = malloc(sizeof(struct foo));
strcpy(out->myname, "bob");
out->big = 1;
out->tall = 1;
out->green = 1;
return out;
}
I don't find the above to be quite as elegant. In fact, it looks ugly
and wasteful; even checking ...
if (myfoo->flags & BIG)
versus
if (myfoo->big)
>
>
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSb1rhDd4aOud5P8RAg2cAJ98SlxFCLcHvN+aWcVTM2VWxiRCEACfUPPl
24wpdtY/VyKHGs/YpPDo8Hk=
=mVc5
-----END PGP SIGNATURE-----