Hacker News Reader

Comment by zxzax | Hacker News Reader

I'm not a kernel developer so I don't understand the details of this part:

>People forget that only a few years ago have we decided that the kernel now has to protect userspace programs from malicious hardware. That's a major shift in thinking, now data that we used to blindly trust can not be trusted at all.

How come this wasn't being done already? Wouldn't you want drivers to do safety checks on everything, in case of a hardware failure? Or does this refer to something else, besides safety checks?

View on HN

If you blindly trust hardware then on potential attack vector is malicious hardware. This used to be known as the Evil Maid attack. If a bad actor get's access to your hardware the thinking goes then all bets are off. And what happens when a significant portion of your hardware is built in a country known to be a bad actor? Well maybe the kernel should start treating the hardware as potential attack vectors now.

A seat belt is a safety feature, while bullet-proof glass is a security feature. The major shift in thinking was that the kernel needed to start adding bullet-proof glass rather than better seat belts.

I don't think I understand that analogy in terms of kernel code, can you give an example of what seat belts and bullet proof glass are in this context? Does that mean that previously in places where they only had CRCs, they added firewalling and cryptographic signing?

A way to detect buffer overflows is by using canary values at the end of the buffer. A hardware failure is unlikely to randomly generate the same value as the canary and you can use this to detect an overflow. Malicious hardware would want to deliberately set the canary to the same value as it was before so as to escape detection, and you need to use something more sophisticated like a random canary value instead of a constant.

Previously, if a USB device was plugged in it then it might work or it might not work and the kernel had to sanely handle both of those cases. The shift is that now the kernel has to handle that USB device actively trying to do something nefarious.

Designing code to be resistant to active malicious attack is very different than just handling error cases for things that don't work.

Probably due to the rise in cloud. Where people run software on hardware which is totally abstracted away from the end consumer.

> Or does this refer to something else, besides safety checks?

I think it largely refers to the Spectre + Meltdown class of attacks, which caused the kernel to introduce a whole class of fixes (retpolines, etc.).

Hmm, I think you're probably right, and I was overthinking it, thanks :)

Spectre and Meltdown are (presumably) not malicious hardware, they're hardware bugs that enable malicious software.

Malicious and failed at not the same thing.

So does that mean there is a significant difference between, for example, a malicious USB device versus a damaged USB device, from the kernel point of view? It seems that both would be sending incorrect data that the kernel should catch, right?

damaged device - sends some random data and prevents link from working, could cause BSOD

malicious device - will send dma requests to read memory and then to send it to some other server or will implant some malicious software in memory or inside other devices.

Reply on news.ycombinator.com