[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ubuntu-hardened] Re: Collecting NX information
Hash: SHA1

Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 14:07 -0500, John Richard Moser wrote:


>>/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.


>>>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)


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
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.037 / U:2.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site