PS/2 handling question

I remember reading or hearing in some video that PS/2, on modern CPUs, is handled more like USB in that the CPU doesn’t directly respond to interrupts anymore, so it basically queues received interrupts and accesses them like it polls USB. (And as a result, any potential benefit PS/2 keyboards may have had over USB at that point had been basically eliminated.)

I have no idea how accurate this is. I cannot find where I heard this, nor can I find any other source to back this up, so I was going to write it off as misremembering things or a lie I read, but I came across this article (and this article), which seems to affirm that interrupts are handled differently, but does not directly support what I remember reading/hearing years ago.

So, my question is: is PS/2 still handled the same way (and thus has no latency), or is it treated more like USB (on newer CPUs)?


Interesting topic. Yeah, all I can find online about PS/2 is questions about why it’s still included on modern hardware and how’s it better / worse than USB.

The articles you linked are specifically how x86 handles interrupts in general, not just PS/2, which as said in the article, hasn’t changed for more than 25 years (and I believe patches have only been created in OS to workaround those x86 issues).

Now, I’m not a hardware engineer (it’s a miracle I even know how a light switch works), so I can’t comment on how PS/2 is being handled in modern hardware. However, I don’t think motherboard manufacturers are adding PS/2 to USB controllers on their motherboards, because otherwise, the so called SECOPS people I keep hearing about online when PS/2 comes into discussion, would complain that they can’t disable all the USB ports altogether from a computer, because the PS/2 would obviously be killed together with it.

So, motherboard manufacturers are actually adding a PS/2 controller on their motherboards.

As seen in this article about Super I/O, PS/2 is connected to an interface, which talks to the CPU through either the southbridge or through the Platform Controller Hub (PCH). Originally peripherals used the ISA (Industry Standard Architecture) bus to talk to the CPU, but with the move to PCI (Peripheral Component Interconnect) bus, a new way to connect Super I/O and “Legacy I/O” devices needed to show up, so LPC (Low Pin Count) bus has been born, which is included in the Southbridge or PCH. The southbridge talks to the CPU through the DMI (Intel) and UMI (AMD).

You cannot connect things to the LPC bus, with the only exception being the industry-loved TPM modules (/s) (yes, these things use the LPC bus), just that most (all?) TPMs are proprietary to the motherboard vendors and thus have custom pinouts and POST codes for diagnostics. (rambling) I have seen articles of people breaking Bitlocker encryption, because TPMs use the SPI / LPC bus, so security experts connected some alligator clips to the bus and read the TPM signals being sent to the bus and so, broken through TPM security without any soldering required. The hack only takes 30 minutes. It kinda makes TPM look like a hassle to disincentivize people to steal data or tamper with devices, as opposed to being actual security, because TPM communicates on an unencrypted channel, thus making it vulnerable to eavesdropping.

LPC bus was created in 1998. Intel introduced a successor to LPC called eSPI (Enhanced Serial Peripheral Interface) and I believe it first appeared on the Intel Z170 chipset. New controllers that use the eSPI have been born.

Anyway, as you can see, it appears that PS/2 hasn’t been “the same PS/2” as people knew it since the 1980s. The protocol itself remained the same, but how it was read changed as time went on. As mentioned, I don’t know hardware engineering, so most details fly over my head. It could be that newer LPC buses have more paths to transverse than the old ISA bus, thus higher latency, or because modern x86 CPUs are so damn fast, we could actually see lower latency, even if we have combined data paths to the CPU, who knows.

But one thing is for sure and that is the answer to your question of how is PS/2 handled. One way or the other, PS/2 is not handled like USB. Again, you can disable USB ports in UEFI and still have PS/2 working and it’s not just a hack on USBs. Then, PS/2 is not shown as a USB device in any OS. Also, PS/2 peripherals still work by interrupt signals. But how these interrupts work remains a mystery for me.

As another anecdote and more rambling, I mentioned secops people. In some companies, the USB ports are completely disabled through the UEFI and only PS/2 keyboards and mice are allowed, because you can use USB devices to add malware or extract data from corporate computers. PS/2, being only used for input prevents it. I never saw a company actually use that, since most OS support blocking USB altogether (I have done it through Windows Group Policy in Active Directory, I believe Linux has similar options too, probably blacklisting USB drivers from loading). But people say these people and companies exist, so I have no reason to doubt it. We’ve seen a recent Windows exploit where you only needed to connect a Razer mouse on an unlocked computer and instantly gain access to the System User, which is more powerful than the Admin users in Windows, because Windows trusts Razer and grabs the drivers automatically. Having USB disabled would prevent this exploit or similar ones, I doubt Razer is the only one in that camp and I think we’d be in for a big surprise if we tried the same trick with other USB printers and peripherals.


That’s very informative and way more detailed than I was expecting. I don’t think I was told it was “the same as USB” or exposed as USB but that it was similar enough that it had effectively the same limitations as USB (i.e. interrupts and low IRQs vs polling didn’t matter anymore).

If they did, they’d probably buy the cheapest ones out there that disconnect if you press the same key in rapid succession.

I’ve seen a PC with all its USB ports superglued as a defense mechanism for this reason. (Not sure if they also disabled at the OS and UEFI levels, but I wouldn’t be surprised - glue shouldn’t be the only measure if you need that level of security.)

1 Like

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.