extending ssp

[Michael Shalayeff]

re
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?
cu
--
paranoic mickey (my employers have changed but, the name has remained)

Index: pftn.c
===================================================================
RCS file: /cvsroot/pcc/cc/ccom/pftn.c,v
retrieving revision 1.332
diff -p -u -r1.332 pftn.c
--- pftn.c 7 Jul 2011 06:50:10 -0000 1.332
+++ pftn.c 18 Jul 2011 18:54:49 -0000
@@ -2856,7 +2856,8 @@ sspend()
p->n_sp = lookup(stack_chk_fail, SNORMAL);
p = clocal(p);

- ecomp(buildtree(UCALL, p, NIL));
+ q = eve(bdty(STRING, stradd("", cftnsp->sname), 0));
+ ecomp(buildtree(CALL, p, q));

plabel(lab);
}

[Joerg Sonnenberger]

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

Joerg

[Michael Shalayeff]

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...
cu

[Joerg Sonnenberger]

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...

You are essentially duplicating the symbol table.

Joerg

[Michael Shalayeff]

Post by Joerg Sonnenberger

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...

You are essentially duplicating the symbol table.

symbol table is not present for installed binaries (typicaly).
thus nothing is duplicated. the addition is a list of function names.
this approximately takes the same amount of bytes as SSP adds itself.
plus to that it's readonly data that does not eat swap etc.
however the benefit for debugging is emmence if you think about it.
cu

[Ricardo Nabinger Sanchez]

Hello Michael,

On Mon, 18 Jul 2011 19:32:38 +0000

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...

You are essentially duplicating the symbol table.

symbol table is not present for installed binaries (typicaly).
thus nothing is duplicated. the addition is a list of function names.
this approximately takes the same amount of bytes as SSP adds itself.
plus to that it's readonly data that does not eat swap etc.
however the benefit for debugging is emmence if you think about it.

How about including, instead, an index into the symtab? If that works,
it could be a balanced approach (ie, it includes the additional bit of
information to ease debugging while not imposing too much space
overhead).

Regards.

[Joerg Sonnenberger]

Post by Ricardo Nabinger Sanchez
Hello Michael,
On Mon, 18 Jul 2011 19:32:38 +0000

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...

You are essentially duplicating the symbol table.

symbol table is not present for installed binaries (typicaly).
thus nothing is duplicated. the addition is a list of function names.
this approximately takes the same amount of bytes as SSP adds itself.
plus to that it's readonly data that does not eat swap etc.
however the benefit for debugging is emmence if you think about it.

How about including, instead, an index into the symtab? If that works,
it could be a balanced approach (ie, it includes the additional bit of
information to ease debugging while not imposing too much space
overhead).

The normal interpreter of the callback prints the address of the caller.
That in turn can easily be converted into the function name using the
symbol table.

Joerg

[Joerg Sonnenberger]

i am sorry but i cannot interpret your meaning for "The normal interpreter."
pcc as a compiler does not pass any arguments to the protector
handler at the moment thus there is no possibility to print anything of use.
typical scenario that i am proposing to improve here would be a production
system that has no symbol tables or core dumps or ktraces attached to every
program in the system. even your average development workstation would
not at all times have your /usr/obj/ populated with installed binaries.
so please tell me how does one gets to the symbol table?

It is pretty trivial to print the address of the calling function from
__stack_chk_fail. It doesn't require any modifications to the ABI or
modifications to the compiler. It can be done completely within libpcc /
libc or whatever. What you want to do increases the size of the binaries
by about the same amount as the symbol table. The symbol table by itself
is a lot more useful and can be used e.g. for nicely formatted backtrace
-- not just stack overflow checks. I don't know what system you are
using. E.g. NetBSD doesn't strip binaries by default, since there is
often little point in doing that. Your patch is essentially a workaround
for using "install -s". Heck, even for a production setting the symbol
table is more useful since it can be pushed into separate files to be
kept along the files send to a customer.

Joerg

[Thorsten Glaser]

Post by Joerg Sonnenberger
It is pretty trivial to print the address of the calling function from
__stack_chk_fail. It doesn't require any modifications to the ABI or

Yes, please do _not_ change that ABI.

bye,
//mirabilos (we have __stack_chk_fail in libc)

[Michael Shalayeff]

Post by Thorsten Glaser

Post by Joerg Sonnenberger
It is pretty trivial to print the address of the calling function from
__stack_chk_fail. It doesn't require any modifications to the ABI or

Yes, please do _not_ change that ABI.

ABI change in this case does not do anything.
arguments that are not used do not harm anything.
cu

[Michael Shalayeff]

Post by Joerg Sonnenberger

i am sorry but i cannot interpret your meaning for "The normal interpreter."
pcc as a compiler does not pass any arguments to the protector
handler at the moment thus there is no possibility to print anything of use.
typical scenario that i am proposing to improve here would be a production
system that has no symbol tables or core dumps or ktraces attached to every
program in the system. even your average development workstation would
not at all times have your /usr/obj/ populated with installed binaries.
so please tell me how does one gets to the symbol table?

my good sir. please endulge me for a few moments more...

Post by Joerg Sonnenberger
It is pretty trivial to print the address of the calling function from
__stack_chk_fail. It doesn't require any modifications to the ABI or
modifications to the compiler. It can be done completely within libpcc /

after a careful consideration of your argument let me ask you this:
what is the use of the function address if there is no symbol table?

Post by Joerg Sonnenberger
libc or whatever. What you want to do increases the size of the binaries
by about the same amount as the symbol table. The symbol table by itself

this may come to you as a disappointment but i have to disagree with you.
list of function names is not a symbol table.
in fact symbol table is way much more but a list of function names.
please peruse your nm(1) and readelf(1) utilities on your binary of choice to
educate yourself a little bit before making such a proposterous statement.

Post by Joerg Sonnenberger
is a lot more useful and can be used e.g. for nicely formatted backtrace
-- not just stack overflow checks. I don't know what system you are
using. E.g. NetBSD doesn't strip binaries by default, since there is
often little point in doing that. Your patch is essentially a workaround

well. let's see. so you are spending heinously times more
space on symbol tables on disk than is required for a list of
function names and arguing about it?

Post by Joerg Sonnenberger
for using "install -s". Heck, even for a production setting the symbol
table is more useful since it can be pushed into separate files to be
kept along the files send to a customer.

well what is your symbol table good for if the binary
is dynamically linked and ld.so performs address space randomisation?
cu

[Michael Shalayeff]

Post by Joerg Sonnenberger

Post by Ricardo Nabinger Sanchez
Hello Michael,
On Mon, 18 Jul 2011 19:32:38 +0000

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff

Post by Joerg Sonnenberger

Post by Michael Shalayeff
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?

It duplicates data inefficiently and in a way that can't be removed from
the binary easily. I don't think this is an improvement.

what is the purpose of striping it?
you might as well simply disable stack protector...

You are essentially duplicating the symbol table.

symbol table is not present for installed binaries (typicaly).
thus nothing is duplicated. the addition is a list of function names.
this approximately takes the same amount of bytes as SSP adds itself.
plus to that it's readonly data that does not eat swap etc.
however the benefit for debugging is emmence if you think about it.

How about including, instead, an index into the symtab? If that works,
it could be a balanced approach (ie, it includes the additional bit of
information to ease debugging while not imposing too much space
overhead).

The normal interpreter of the callback prints the address of the caller.
That in turn can easily be converted into the function name using the
symbol table.

i am sorry but i cannot interpret your meaning for "The normal interpreter."
pcc as a compiler does not pass any arguments to the protector
handler at the moment thus there is no possibility to print anything of use.
typical scenario that i am proposing to improve here would be a production
system that has no symbol tables or core dumps or ktraces attached to every
program in the system. even your average development workstation would
not at all times have your /usr/obj/ populated with installed binaries.
so please tell me how does one gets to the symbol table?
cu

[Martin Husemann]

typical scenario that i am proposing to improve here would be a production
system that has no symbol tables or core dumps or ktraces attached to every
program in the system.

Typical reaction of the stack protector handler would be a core dump. If you
don't have symbols installed, just recompile with them and use the core
against the new objects. For an important system, I'm sure you kept the
exact source tree around.

Martin

[Michael Shalayeff]

Post by Martin Husemann

typical scenario that i am proposing to improve here would be a production
system that has no symbol tables or core dumps or ktraces attached to every
program in the system.

Typical reaction of the stack protector handler would be a core dump. If you
don't have symbols installed, just recompile with them and use the core
against the new objects. For an important system, I'm sure you kept the
exact source tree around.

core dumps? you do keep 'em lying around on your production systems?
if you can afford space for a core dump than tiny little string table
would not bother you either right?
cu

[Anders Magnusson]

Hi,

just back from vacation, and this was an interesting discussion :-)
Anyway, gcc gives arguments to the fail handler, and at least some code
in glibc uses it, so we should try to be compatible with gcc and not cause
unexpected segfaults.

-- Ragge

Post by Michael Shalayeff
re
i would like to extend stack smashing protector with an additional
argument for the fail handler -- the function name.
i suppose it's obvious usefulness for debugging purposes.
opinions?
cu