I wonder if any of these chips ended up in electronic voting machines?

That is one place you don't need hacking CPUs to hack the result. Plain files vetted by no one etc etc.

I would not be surprised, it was one of the earlier low TDP but x86 compatible chips.

> ... and embedded in ATMs with a 20 year life span.

Privilege escalation is not a problem on ATMs.

> It pains me terribly every time I power up the Agilent signal analyzer in the lab and it boots Windows XP on its Pentium III chip.

Why? Just treat it as you do most hardware, under full control of whatever you attach it to. Zero security present, zero security needed.

> Privilege escalation is not a problem on ATMs.

https://vuldb.com/?id.79002

I expect that most people miss that ATM manufacturers continue to put security holes in ATMs (https://www.wired.com/2014/11/nashville/) one of the 'fixes' was to make bank access unprivileged. But wait, if I have an escalation vulnerability ...

Sigh. Okay let me rephrase. The thing normally called "privilege escalation", where software that is executing on a machine escapes a sandbox or gets into kernel mode, is not a problem on ATMs.

That page is talking about pressing keys to exploit software flaws in already-privileged software, which is an extremely separate topic.

Privilege escalations come in many shapes and sizes, it is not limited to software escaping a sandbox or to get into kernel mode, it is also explicitly used to refer to users of a system managing to leverage their normal access into a more powerful one.

But in context I was clearly talking about the former, because the topic is software exploiting CPU backdoors.

This can be combined with another exploit that allows the user to execute user code to achieve root on the ATM, so it's still troubling.

I don’t think these ATMs run a lot of untrusted code, and this is of course easily patched by clearing the bit during the boot sequence.

It would be much more of a problem if these were consumer machines running untrusted code.