Agreed, the software based approach does not take a significant
performance hit, but the hardware approach is transparent to the user
and does not require recompilation of the source code. Therefore, all
programs can run securely on a machine whether or not they are "compiled
securely" (e.g. legacy software).
The idea is not to create "custom CPUs" but to have our modification
picked up by major vendors. Clearly there is interest in applying
hardware to solve security issues based on the latest press releases
from AMD that AMD chips include buffer-overflow protection (see
Computer World, January 15, 2004).
--The SmashGuard Group
On Tue, 3 Feb 2004, Dave Paris wrote:
... I'm not sure I understand the economics involved here. Taking the
... worst-case (software) cited at an 8.3% performance hit, this says a 3.2GHz
... P4 will give approximately the same performance as a 2.9GHz machine. Or put
... another way, for every 12 machines I have operating on a problem (say, in a
... cluster of some sort), I have to add in one additional machine to make up
... for the performance hit. If we're talking about commodity, x86 server type
... hardware, we're not talking about a lot of money, even if you factor in the
... additional costs for another switch port, etc. Certainly not the kind of
... money one would expect to be kicking around for custom CPUs - which I would
... guess to be _well_ in excess of SPARC or PA-RISC prices.
...
... I think the project/product is quite interesting from an academic
... standpoint, but unless it can be put into mainstream production with
... existing vendors, my realistic side says it'll never be economically
... feasible to get out of academia.
...
... Kind Regards,
... -dsp
...
... -----Original Message-----
... From: Hilmi Ozdoganoglu [mailto:cyprian (at) purdue (dot) edu [email concealed]]
... Sent: Friday, January 30, 2004 6:34 PM
... To: bugtraq (at) securityfocus (dot) com [email concealed]
... Subject: http://www.smashguard.org
...
...
...
... SmashGuard is a hardware-based solution developed at Purdue
... University to prevent Buffer-Overflow Attacks realized by overwriting the
... Function Return Address (patent-pending). The design of SmashGuard is a
... kernel patch that supports CPUs modified to support SmashGuard protection.
...
... For details please refer to the TechReports at:
...
... http://www.smashguard.org
...
... In addition to details of SmashGuard, the site serves as a comprehensive
... resource for buffer overflow attacks/prevention/detection. On "the buffer
... overflow page" we provide links to research papers, known exploits, safer
... C languages, patents, audit tools and more. If you can think of a site or
... resource that should be added please send email to our webmaster
... (cyprian (at) purdue (dot) edu [email concealed])
...
... -SmashGuard Group
...
...
...
...
...
Agreed, the software based approach does not take a significant
performance hit, but the hardware approach is transparent to the user
and does not require recompilation of the source code. Therefore, all
programs can run securely on a machine whether or not they are "compiled
securely" (e.g. legacy software).
The idea is not to create "custom CPUs" but to have our modification
picked up by major vendors. Clearly there is interest in applying
hardware to solve security issues based on the latest press releases
from AMD that AMD chips include buffer-overflow protection (see
Computer World, January 15, 2004).
--The SmashGuard Group
On Tue, 3 Feb 2004, Dave Paris wrote:
... I'm not sure I understand the economics involved here. Taking the
... worst-case (software) cited at an 8.3% performance hit, this says a 3.2GHz
... P4 will give approximately the same performance as a 2.9GHz machine. Or put
... another way, for every 12 machines I have operating on a problem (say, in a
... cluster of some sort), I have to add in one additional machine to make up
... for the performance hit. If we're talking about commodity, x86 server type
... hardware, we're not talking about a lot of money, even if you factor in the
... additional costs for another switch port, etc. Certainly not the kind of
... money one would expect to be kicking around for custom CPUs - which I would
... guess to be _well_ in excess of SPARC or PA-RISC prices.
...
... I think the project/product is quite interesting from an academic
... standpoint, but unless it can be put into mainstream production with
... existing vendors, my realistic side says it'll never be economically
... feasible to get out of academia.
...
... Kind Regards,
... -dsp
...
... -----Original Message-----
... From: Hilmi Ozdoganoglu [mailto:cyprian (at) purdue (dot) edu [email concealed]]
... Sent: Friday, January 30, 2004 6:34 PM
... To: bugtraq (at) securityfocus (dot) com [email concealed]
... Subject: http://www.smashguard.org
...
...
...
... SmashGuard is a hardware-based solution developed at Purdue
... University to prevent Buffer-Overflow Attacks realized by overwriting the
... Function Return Address (patent-pending). The design of SmashGuard is a
... kernel patch that supports CPUs modified to support SmashGuard protection.
...
... For details please refer to the TechReports at:
...
... http://www.smashguard.org
...
... In addition to details of SmashGuard, the site serves as a comprehensive
... resource for buffer overflow attacks/prevention/detection. On "the buffer
... overflow page" we provide links to research papers, known exploits, safer
... C languages, patents, audit tools and more. If you can think of a site or
... resource that should be added please send email to our webmaster
... (cyprian (at) purdue (dot) edu [email concealed])
...
... -SmashGuard Group
...
...
...
...
...
[ reply ]