This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
GCC developers, Although my background is in compilers, I'm not up on the current nuances and ramifications of nonstandard calling conventions, so I don't feel qualified to modify GCC myself. However... My goal is to get the idea below across to more people. Please forward my original message to all appropriate parties. I just ask that you cc: blodgett@mitre.org when you do so. Thank you. --- Bruce Richard Stallman replied: ... > As for why this calling convention is not used, that is partly because > GCC supports the standard calling convention of each machine. To use > a nonstandard calling convention is rather a pain. > > But it is not impossible. If someone wants to do it, I guess that > implementing the nonstandard convention in GCC would be the first > step. > > If you are interested in working on it, please write to gcc@gcc.gnu.org. -------- Original Message -------- Date: Mon, 16 Jul 2001 18:28:24 -0400 From: Bruce Blodgett <blodgett@mitre.org> To: rms@ai.mit.edu Hello. I'm concerned about the current lack of security in today's operating systems and core applications. I have an idea that seems obvious to me, and am looking for help in communicating it to those who can implement it. Given that buffer overflows account for a huge number of exploits: Why don't the OS developers simply compile their code in such a way that all (currently stack-based) buffers and (currently stack-based) return addresses are allocated in unrelated separate storage areas? (Then, knowing one address would be of no use in determining the other, so overflowing a buffer could not overwrite the return address). I find it hard to believe that the current Vulnerable Stack Layout (VSL) is the only efficient layout. If there exists a NonVulnerable Layout (NVL) that is similarly efficient, I find it surprising that compiler writers still implement today's VSL. Even if the best NVL sacrifices a little efficiency for the sake of security, I'm surprised that NVL isn't the default. The more efficient VSL could still be used whenever the compiler can guarantee (or the aggressive user switch promises) that the resulting generated code is not vulnerable to buffer overflow attacks. Bruce Blodgett Mitre Corporation (781) 271-7813 P.S. Any ideas regarding implementation of an efficient NVL? P.P.S. How can I spread this idea to those who can effect this change?
S/MIME Cryptographic Signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |