3 ms·

Re. #1, Harvard architecture also does not solve problems with source code injection attacks, as we see with SQL queries and complex data structures that direct

Re. #1, Harvard architecture also does not solve problems with source code injection attacks, as we see with SQL queries and complex data structures that direct the flow of execution. Harvard architecture is a pain in the ass anyway. When I designed a Harvard architecture chip (8051 derivative) into a product, I added an external address space mapper to turn it into a von Neumann architecture. The software folks had to write a custom file system/linker/loader and were thankful. The alternative was painfully reprogramming the chip with every recompile. Re. #5, the large system developers I know love them their C# and sing the praises of Microsoft for making C/C++ avoidable. Their 500 kLOC distributed system integration project would be nearly untenable if they had to manually get every container iteration and bounds check exactly right. And Microsoft does not talk about it much, but I get the impression that they have been running heavy code reviews and static analyzers on their C/C++ software. At least there seems to have been a decline in exploitable bounds check errors.

tptacek 16y ago
Every piece of Microsoft software that has a customer-visible name --- and many that don't --- have been run through a gauntlet of static source code analyzers, have been reviewed by developers trained in secure C/C++ programming, have been "threat modeled" by internal and external teams to find design alternatives that reduce exposure to threats, and have been subjected to multiple external pen tests, often on the dot release. The result is demonstrably imperfect, which just underscores the point that we don't know how to produce secure software "in the large". Here's a shorthand: if Daniel J. Bernstein can't get it right, it's absurd to suggest that any software company's going to do any better.

tptacek 16y ago

Every piece of Microsoft software that has a customer-visible name --- and many that don't --- have been run through a gauntlet of static source code analyzers, have been reviewed by developers trained in secure C/C++ programming, have been "threat modeled" by internal and external teams to find design alternatives that reduce exposure to threats, and have been subjected to multiple external pen tests, often on the dot release. The result is demonstrably imperfect, which just underscores the point that we don't know how to produce secure software "in the large". Here's a shorthand: if Daniel J. Bernstein can't get it right, it's absurd to suggest that any software company's going to do any better.