Some general news that you may or may not have come across yet. It's not 6502 admittedly, but if you have an Intel CPU you might want to have a read. Not everyday your OS of choice (Windows, Linux, MacOS) has to be patched to circumvent a 5-year-plus old massive kernel exploit and make your CPU 5%-30% slower for I/O & interrupt based stuff.

https://forums.theregister.co.uk/forum/ ... sign_flaw/

AMD users are fine. Sadly, I have an Intel CPU in all my stuff .

Yea, this is pretty much a drag for us. It won't affect us immediately (because we run with an ancient kernel), but we'll be upgrading soon.

It's annoying because we just tossed another pair of CPUs in to our main DB box to ideally lower the overall load, and this new kernel will essentially outright consume 1+ of those in overhead. Synthetic DB benchmarks are reporting a hit of 15-20% (!!).

Yay.

I've always said the 8085 was Intel's best - it's been all downhill since then.

Fortunately, we haven't built anything with Intel MPUs since around 2005. Opterons in servers and high end workstations, Athlon64s in everything else.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

AMD is, according to AMD, fine, but unfortunately this problem seems to affect more than just Intel. It's not a hardware bug per se as I understand it (as in: a mistake in implementation), it's the whole concept of getting speed by implementing TLBs in a certain way. So there's also a software workaround being worked on for 64-bit ARM, and some other architectures (but apparently SPARC is fine). The big problem is that it can't be fixed in microcode, and the sw workaround totally kills performance (down 50%) whenever you have to go from user to kernel mode (as you do *all the time* when using e.g. threads on Linux) because the TLB has to be flushed. And it looks like a proper (future) hardware fix may also give a performance penalty because speculative processing simply can't be done in that particular way.
At least yesterday it was not yet clear if this problem will allow a VM to break out of the hypervisor, if it does then it's total disaster - every virtual server provider will have to shut down and update, and as for my local box I won't be able to protect myself (and keep the performance) by just moving all my web browsing to a VM on my own host - javascript can be used to exploit this.

My favorite part was about the "Forcefully Unmap Complete Kernel With Interrupt Trampolines".

_________________
Cat; the other white meat.