61–70 of 137 posts
Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks. Untrusted code execution must go, that's the only way. The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.
Earlier quoted context omitted.
It is known since... forever?, that one should not speculate across security boundaries. This was not enough to avoid Spectre, but this was largely enough to avoid TONS of security vulns Intel is also susceptible to. Somebody messed-up big time. Or from a business point of view did they? Intel current problems are manufacturing and the continuously lower power of their "legacy" processor (except due to manufacturing…
>It is known since... forever?, that one should not speculate across security boundaries. ... if you value security over raw performance. Clearly Intel has decided at some point that it was worth playing with fire in order to get ahead in benchmarks. In their defence it seems to have worked reasonably well for them for quite a while. >The people most annoyed are the users. I wish, but I wonder how much of that is tru…
Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With no…
Again, I reiterate: it's not humanly possible to make performant, general purpose CPU that is 100% safe from instruction level attacks. Untrusted code execution must go, that's the only way. The genie is out of the bottle now. There will be more and more practical instruction level attacks with each year now.
These CPU vulns have all been related to performance optimizations. Do you have any reason behind your claim that a CPU without such optimizations would be vulnerable?
My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
Earlier quoted context omitted.
You can avoid instruction-level attacks by putting untrusted code on an isolated core with an isolated memory module, right? That seems more likely to me than everyone disabling javascript.
> You can avoid instruction-level attacks by putting untrusted code on an isolated core with an isolated memory module, right? No, unfortunately. Side channels will work even across numa domains, and cores with own memory. Side channel free hardware is extremely hard to do even in simplest ISAs specially made for that. Look at how credit card industry keeps struggling making safe smartcards.
And we should be able to eliminate anything weaker.
Earlier quoted context omitted.
I don’t think so. Side channel attacks became recently more mainstream and people start designing stuff with it in mind. What you see here is yet another attack on a relatively unused Intel-only x86 extension. The bigger problem is that Unixes and Windows are pretty bad at sandboxing syscalls by default.
I do remember there 100% were academic papers throwing barbs into Pentium 3 branch predictor security back in nineties. They just went unnoticed for there being no Google logo on the paper. People in hardware engineering community knew of their existence long ago. It was just them not being practically exploitable that kept them from headlines. But now we have a multibillion buck virtualised hosting industry, and JS…
Google wasn't nearly as big a deal back in the 90's (hell, they were only really around the last couple years of the decade) so that's a weird association to make.
Earlier quoted context omitted.
The problem TSX is attempting to address is bus traffic from those exact lock instructions you mention. These work OK for the relatively small core counts of today but won't scale to hundreds of cores. TSX brings hardware supported optimistic locking and breaks the latency imposed by MESI and related protocols in use today. Of course its great if you can get away with no synchronization at all - but then you might as…
I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work. Obviously many workloads require some coordination, but often something as trivial as allocating one of a given resource per CPU is sufficient to avoid most contention even on 100s of CPU core machines. Profile; improve. The same is required with HTM. Reg…
I’m going to nitpick, though.
> I explicitly mentioned memory model atomics in addition to locked instructions in an attempt to prevent getting hung up on locked atomics. I guess that didn't work.
By “memory model atomics” do you mean atomic loads and stores rather than, say, compare-and-swap or atomic-increment? Because C++11 compare-and-swap and atomic-increment operations take a memory ordering parameter, yet they still generate the same `lock cmpxchg` and `lock inc` instructions.
But the issue isn’t locks; none of those instructions actually lock the entire memory bus like in the old days (...unless you pass an unaligned address!). They lock the cache line, which causes cache line thrashing if many processors do it at the same time, and that’s the biggest source of overhead. But plain stores also lock the cache line. A compare-and-swap is more expensive than a plain store, but not that much more.