Hacker News Reader

Comment by rodonn | Hacker News Reader

Unclear that diversifying helps solve this sort of problem. More vendors could lead to the same number of bugs, but less investment in quality control per product e.g. if you make $1b and spend 1% on quality control, then you spend $10m checking your product for bugs. If the market fragments into 10 $100m vendors, then to get the same amount of money spent checking each chip for bugs, you'd have to spend 10x as much of your budget on quality control.

It gets even worse when you consider the incentives of private/academic/third party researchers to search for bugs, since there is a lot less prestige in catching a bug in a smaller/less well known product. e.g. I'm pretty sure no white-hat security researcher has checked for security problems in the cheap wifi light switches I bought on Amazon.

View on HN

> If the market fragments into 10 $100m vendors, then to get the same amount of money spent checking each chip for bugs, you'd have to spend 10x as much of your budget on quality control.

But there's a much smaller attack surface and the incentives for attackers are significantly changed. Homogeneity is always more vulnerable to disaster, whether we're talking about food supply or chips.

And quality is not directly a function of money spent. Customers will start demanding to see the machine checked proofs that your hardware is correct. Intel has been cowboy coding CPUs for way too long.

> Unclear that diversifying helps solve this sort of problem.

At least having the option of another vendor as a fallback (e.g. in case there's a severe RCE vulnerability in ME/PSP) is a better alternative than having to shutter your entire business.

I would not be surprised if these management engines have a backdoor that can be invoked from a guest VM... and then an all-Intel (or all-AMD) shop has a massive problem.

Intel ME drivers are not loaded into a VM, the devices are not exposed and the ME MSRs are also not exposed.

> and the ME MSRs are also not exposed.

This is the core question: is this isolation absolutely perfect, or can it be pierced in any way? Something on a severity level like Spectre/Meltdown - people would have laughed you off the stage half a year ago when you told 'em you could read kernel memory from Javascript without exploiting both the browser and the kernel - is IMHO certain to be present in either of the "management" solution, and I'd like to be prepared when the bomb explodes.

I don’t think any serious security person would have laughed you off for mentioning side channel attacks.

No isolation is perfect but and that is an important but for virtualization you have much higher control over what instruction you allow through so an attach which is specific to ME isn’t likely.

That said you can have a side channel attack that allows you to compromise the hypervisor and from it you can jump to the ME but this is a different story.

> e.g. I'm pretty sure no white-hat security researcher has checked for security problems in the cheap wifi light switches I bought on Amazon.

But isn't this also applicable to the other side? As in, black hats have less incentives to research vulnerabilities in less popular products (security through minority). I'm not certain how this balances out.

Cheap products can be quite popular. It's probably fine until that cheap item you bought goes viral on facebook, or there is a single upstream vendor that is hugely successful. No idea either, only statistics would tell.

AMD chips do not need PTI. All the performance hits people are talking about right now would be irrelevant on a cloud farm that used AMD CPUs for their hosts. If any such cloud farms exist, they had better be declaring that loud and proud; I expect there will be a lot of people looking to jump ship.

Different vendors have different bugs.

The aerospace industry has realized this a long time, and for some things they will have 3 different devices from 3 different vendors doing the same job

Reply on news.ycombinator.com