You make decent points but are missing the bigger picture: vast majority of problems with security, esp code injection, are caused by mechanisms or design patterns that create insecurity by default. It takes insane amounts of effort to use the basic, building blocks on complex applications without creating problems. The building blocks themselves are often simple or can be made that way. That you say the robust methods only work on the simplest stuff is actually an endorsement of my approach if we focus them on building blocks. That's what I mainly push it for so let's test my theory with a real-world example.

We'll only use techniques from production systems made before the 80's, that were commercially successful, and that exist today in some form. Should make it easy to argue practicality. Gives us Burroughs B5500 (1963) and IBM System/38 (1979). Pointers are tagged for protection, actual value inaccessible by apps, and created by program loader only. Memory is tagged as code or data during load time with all input from I/O tagged as data by default by hardware. Any input can't be executed unless administrator explicitly allows it and it's actually the compiler that does that anyway since apps come as source in type-safe, HLL in Burroughs model. Interfaces are checked during compilation, too. Processor checks these on every instruction. Also does bounds checking, overflow checking, type-checking of function call arguments, and stack protection. Checks and processor run in parallel for performance with final state not written unless check passes. So, you can't smash pointers, arrays, buffers, stacks, or individual data with overflow: all just generates exceptions which are recovered from or freeze app with admin notification.

So, you want to hijack the app via a corrupted PDF or network packet. Assume, as you said, that the simple mechanisms above were implemented at EAL6-7 and apps just used them. Where would you start with a software attack (no rowhammer lol) with input to an app if you only got exceptions when hitting pointers, data fields, memory management, stacks, and arrays/buffers? What's left? If you're claim is true, then these simple modifications provide no meaningful increase to the reliability or security of our systems. There's other security risks but I'm focusing on code injection via attacking software with input. I predict attacker's job is so difficult in this model that most would go for social engineering or sabotaging executables to attack compiler/installer/loader. Those are also protected by these mechanisms and ruggedly built (eg Ada or SPARK w/ all checks on). You're actually more knowledgeable and skilled than me at the many implementation attack methods. How many are left at this point? Seriously, so I can counter them too.

Funny you mentioned hardware. It certainly does have errata here and there. Yet, that's despite tens of millions to billions of transistors running concurrently. Its error rate is actually incredible. I wonder why. Let's look at design flow for Intel, IBM, etc.: specs to RTL to gates with equivalence checking at each layer; lots of testing; formal verification (Intel) and falsification (IBM) of stuff at various layers; synthesis tools with validation approaches to that; generic components with interfaces and timing analysis; gate-level testing to see where tools were lying; comparisons of instrumented chip to the models after a fab run. The difficulties were overcome by constantly investing in tools for various problems and heuristics that made them work better. Guess what? Those methods look very similar to the B3, A1, EAL6, and other assurance activities. They also worked: quality in terms of errata varied from staying steady to improving over time despite exponential increases in complexity.

Believe it or not, you don't need to verify a whole system at highest levels. I'm not even promising absolute security from the effort: just saying systems designed this way have had incredible resilience to pentests, faults, and external attacks. I say invest the effort into mechanisms like above, languages immune to what we can, analysis tools catching what we can, compilers, most-used parts of kernels, interfaces (esp glue), parsers, and so on. These have already been built rather than theory: really just re-applying existing work to new system. Less than 1% of code and design done right knocks out 99% of routes for code-injection and many other issues in the rest of the system. The rest we catch with security research and reviews. Or recover from after monitoring detects problems.

So, Thomas, would you trust an x86-style processor with a monolithic kernel coded in C? Or a system like EROS running on my above CPU that only uses safe mechanisms (hardware-enforced), safe languages, and robust tools for making one properly use the other? Even if COTS-style implementation, the amount of vulnerabilities and their severity should nose dive. Your current position is that 400 kernel and thousands of user-level vulnerabilities resulting in malware execution are better than thousands of user-mode exceptions, a few kernel-exceptions, and maybe a few injects from what we didn't see coming. I disagree and think we can do better. Friggin 1960's-1970's tech had better security & reliability than current architectures! Academics (see crash-safe.org or CHERI) have with way less time and money than Intel, IBM, etc. So, why do you speculate? Methods that got results against problems before will get results against same kinds of problems again. Just need to apply them and in most cost-effective way. All I preach.