User: nevark

If you don't have time to do it Right...

On: Making Software Suck Less

> Adding a feature will take the same amount of > time whether you do it now or in the future. I have to disagree. Six months from now, you will likely have forgotten many important details about how your system works. It will probably take you longer if you postpone, as you will have to spend time regaining context. I often find that if I am working on a particular problem, then get pulled away for a week or two, I will have to burn several days, just re-learning the idiosyncrasies that I had previously known so well.

Re:Will it give a false positive on wrapper funcs?

On: Libsafe: Protecting Critical Elements of Stacks

So apparently, the strcpy_wrapper function example, will be taken care of because they traverse the stack to determine which frame the buffer lies in.

But the question of buffers on the stack still remains. I suppose that they could make the special case that if the buffer in question is not found to lie anywhere in the stack, that it must be in the heap, and therefore is safe from corrupting the return address. (BTW - change the malloc in the above to malloc(strlen(s)) ).

Will it give a false positive on wrapper funcs?

On: Libsafe: Protecting Critical Elements of Stacks

As I understand how the thing works, it calculates the frame size of the calling function, and uses that as the upper bound. But what happens if the buffer that you are copying into is a stack variable from a *previous* frame? That is, if I write a function:

char *strcpy_wrapper(char *s1, char *s2) {
printf("You just called strcpy()\n");
return strcpy(s1, s2);
}

When strcpy gets called, libsafe will calculate the frame size of strcpy_wrapper to be about zero bytes, then declare that the call to strcpy would overrun the stack.

A similar problem would occur if I did:

char *squirrel(char *s) {
char *c;
c = malloc(4 * 1024 * 1024);
strcpy(s, c);
return c;
}

Or, am I missing something?