Hector Martin

Oh, I am not saying that I'm saying that ancient turtles or new turtles, it's turtles all the way down

And yet that's not a good argument for spending millions on supporting those barely functional systems.

Some of them were stringently tested by the government in the 80s. There used to be standards for computer security designed by military. That kind of standardization and testing just doesn't tend to happen anymore except for a very few niche companies.

Modern computer programming is too much of a moving target. And, in the name of speed, we sacrifice a lot of security-first principles. https://en.m.wikipedia.org/wiki/Meltdown_(security_vulnerability) … for example. Compare to AS/400 architecture, where CPU are designed less efficiently in order to be secure.

AS/400 isn't a CPU architecture though, it uses machine independent bytecode (like Java, Android dex, LLVM IR in iOS apps, and other similar modern versions). The actual CPUs used by AS/400 have been POWER for a while and certainly are vulnerable to Spectre subsets.

By the way, z/OS and friends are lacking many modern security mitigations. I wrote a CTF for z/OS USS that was a trivial stack overflow, which would've instantly been caught by stack cookies on any modern system, and made harder to exploit by ASLR.

As far as I can tell, any idea that all that big iron stuff is "secure" is a bunch of wishful thinking. Nobody is auditing those systems from the POV of modern exploitation because they're so niche and proprietary, so nobody is pumping out the CVEs. It's security by obscurity.

Security thru obscurity might be a fair assessment. I don't trust software design for big iron to be secure, but I had read a whitepaper ages ago describing how AS/400 was designed for extremely high reliability and to discourage low-level side-channel attacks. Can't find it now