Hacker News new | comments | show | ask | jobs | submit login

What's the definition of a 'backdoor' here? As someone who implemented a version of ARM and MIPS in VHDL, I'm having a hard-time picturing a 'backdoor' in a CPU.

In fact, I'm tempted to classify this article as 'complete non-sense', only believable by someone who has no idea what a CPU is. Given some of the comments about the Linux 'kernal' (sic), I'm not surprised this article made it to the front page of HN.




CPU backdoors that work by exploiting known software are entirely imaginable. Think of a situation where the bad guys target the network stack. They make a CPU that always executes instructions in exactly the correct way, except that if certain registers are filled with precisely specific data, the CPU turns of protection and suddenly jumps into whatever is pointed by one of the registers. Then target a network packet handling routine with that -- so if a specific malformed packet is received, the cpu jumps into the data payload. If your magic data is long enough (4 32-bit registers would be enough), no-one will ever trigger it by accident.

Doing this would be trivial with the microcode in modern x86 cpus, and while it would break (no longer trigger) if the netcode is updated (or even recompiled), that's rather rare, and cpu ucode can be updated too.


Never have done hardware design but is it not possible to say after specific instruction sequence to make the CPU:

1. Not honor NX bit 2. Mess with RNG 3. Give constant ASLR on reboot

These alone can go a long way to compromising a system.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: