CPU Security Flaws MELTDOWN and SPECTRE
I think it's more likely they just sell it as a performance upgrade, showing graphs of how the new CPUs are faster than the old ones (that have mitigations on ofc), without mentioning the bugs other than in the small print.
hoom
Veteran
Intel microcode update in latest Windows release https://support.microsoft.com/en-us...or-windows-10-version-1803-and-windows-server
So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it?
Actually, rowhammer is a RAM manufacturer problem. The reason why virtual-to-physical mapping is now believed to be better kept secret (from the process which owns the virtual address) is mostly because of rowhammer. If there's no rowhammer, it'd be practically a non-issue.
It doesn't matter. If there's no rowhammer, there's no point in hiding virtual-to-physical mapping from the running process. The fact that some ARM and AMD CPU (note that they don't actually test a lot of different ARM and AMD CPUs, so it's not clear whether newer ARM and AMD CPUs are actually immune) does not leak this information does not change that the whole thing would be a non-issue if there's no rowhammer.
The reason why CPU and OS have these protections against rowhammer is simply because there are just too many DRAM modules out there are susceptible to rowhammer and it can't be easily fixed. It does not change the fact that rowhammer is a design failure of DRAM modules, not CPU and OS. Once rowhammer resistant DRAM modules become widely available, it'd go back to be a non-issue.
As previously noted, Rowhammer is a DRAM failure. In the past, bit upsets due to neighboring row accesses would have been a reason to fail DRAM at the factory, and when this was discovered the vulnerable products were not acting in accordance to their specifications. That people have moved to secondary mitigations or software is an indication that the DRAM products affected were too widespread to recall or that the reality going forward was that density would come at the price of discarding old standards of array reliability.So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it?
However, there are notable use cases for knowing the physical memory layout of data like IO, NVRAM (big reason why some key instructions exist), and high-performance code. Memory controllers and DRAM modules have limited ranges where they can provide sustained bandwidth and consistent latency based on the physical access patterns. As such, this is likely too important of a case for software to be denied knowledge of the physical address space. I think OS developers are trying to find ways of providing privilege levels for getting this information, which was something that could be queried or derived rather freely up until recently.
Besides, this is just one side channel. The cache hierarchies, TLBs, and page table layouts are perhaps further out from the memory reorder buffer, but they have well-documented and not-difficult channels for leaking physical address information. There's no likely change on the horizon for ripping out the x86 virtual memory architecture or changing all caches past the L1 to anything but physical addressing.
As far as counting on software with secret information to be modified to not have path selection based on hidden values, that's been standard cryptographic practice for decades. Secret values are not to be used by instructions or units whose behavior may change based on the contents, or the usage should be obfuscated by stalls or parallel make-work that creates external behavior that is indistinguishable. New side channels or missed exploits are usually reasons to change the code, since almost all execution outside of these limited exceptions considers this behavior to be unimportant, acceptable, or expected.
In that regard, certain attacks using physical address leaks would be worse on a system using AMD's recommended setup, since a subset of attacks are related to kernel address space mapping leaks fixed by the KAISER changes repurposed for Meltdown.
It can come down to specific implementation choices or the algorithm used.
There may also be northbridge or system-level mitigations for problematic patterns that might make such patterns more difficult to sustain, or might make leaking the physical mapping less impactful.
The AMD chip I saw listed was Bulldozer, whose specific OoO memory implementation was not really disclosed in years past. There could be corner cases that could correlate physical addresses that just differ from the subset of bits Intel used, or from my recollection discussion for Bulldozer's forwarding and disambiguation schemes were that they were more fragile or obscured by other architectural stalls and pitfalls. The weaker load/store pipeline and the unconventional write-through to a write-combining cache that spilled into an insufficient L2 could provide enough of a shadow to lose modest latency spikes versus a generally high-performance Intel scheme with an isolated set of longer mispredicts or a sub-optimal replay mechanism.
AMD's Zen has been tested to have a more robust speculation pipeline, although testing may be complicated by other forms of speculation that occur within the register file and renamer prior to getting out to the store queue. The store queue which would function using physical addresses and might have its own layer for speculation that could have a timing side channel.
The general case is that a subset of bits or a hash function using an unknown number of bits (likely >48 bits) is discussed, meaning there could be gaps that could be exploited to varying degrees if they were as well-known.
The ARM chip I saw listed was a Qualcomm version of the A73, which is just one ARM core of many. Of note, there is a different store to load forwarding mispredict exploit that AMD, Intel, ARM, and others do have exposure to in various products (variant 4) where measures for restricting speculation on store forwarding exist. Some ARM cores do have microcode changes to expose these methods, so they may have a somewhat different implementation for speculation.
Of the ARM vendors, I would be curious about Apple. For one thing, Apple's cores are significantly higher-performance, IOS products got Meltdown-related changes as well, and Apple and Intel ran into litigation surrounding the same memory disambiguation patent.
The presentation slides go into more detail about the on-die fabric and significant debugging and trace capability.
There's a primary data fabric that extends PCIe semantics, connects IP blocks, and allows for third-party integration. There's a base fabric unit, various addressing methods, and bridges from the internal fabric to various external or legacy buses.
Much of this is reminiscent of another vendors more publicly marketed fabric.
There's also a sideband bus with more miscellaneous traffic and a JTAG bus for testing.
Various exploits attempt to set system variables to unlock an access level that can reach all levels of fabric, clients, and the signals and tracing available with the VISA infrastructure.
As noted, these are validation and testing tools for a complex and high-performance collection of internal systems.
Using this means local access and essentially running a setup for testing and validating the chip--whose wealth of tools and counters can give side-channel information or avenues for touching elements assumed inaccessible outside of a factory test-bench.
While there seems to be a fuse-based way of locking this out, it appears to be unset.
I'd be curious what methods other vendors have for this. All such chips would have some kind of infrastructure for validation and testing. Whether they lock things out with more layers of security or physical/electrical barriers like fusing is unclear.
As an example, when AMD's Ryzen chips were experiencing segfault errors, they were asking for chips to be returned. That could have been an opportunity to analyze what on-die elements were failing, or could serve such a role in any future post-launch problems.
Possibly, the desire for such a capability may explain why Intel and presumably others might not have made the cut-out for this kind of functionality physical.
There's a primary data fabric that extends PCIe semantics, connects IP blocks, and allows for third-party integration. There's a base fabric unit, various addressing methods, and bridges from the internal fabric to various external or legacy buses.
Much of this is reminiscent of another vendors more publicly marketed fabric.
There's also a sideband bus with more miscellaneous traffic and a JTAG bus for testing.
Various exploits attempt to set system variables to unlock an access level that can reach all levels of fabric, clients, and the signals and tracing available with the VISA infrastructure.
As noted, these are validation and testing tools for a complex and high-performance collection of internal systems.
Using this means local access and essentially running a setup for testing and validating the chip--whose wealth of tools and counters can give side-channel information or avenues for touching elements assumed inaccessible outside of a factory test-bench.
While there seems to be a fuse-based way of locking this out, it appears to be unset.
I'd be curious what methods other vendors have for this. All such chips would have some kind of infrastructure for validation and testing. Whether they lock things out with more layers of security or physical/electrical barriers like fusing is unclear.
As an example, when AMD's Ryzen chips were experiencing segfault errors, they were asking for chips to be returned. That could have been an opportunity to analyze what on-die elements were failing, or could serve such a role in any future post-launch problems.
Possibly, the desire for such a capability may explain why Intel and presumably others might not have made the cut-out for this kind of functionality physical.
New ZombieLoad attack discovered on Intel CPUs. Whitepaper discuss:
Looks like everything since sandy bridge until kaby lake is affected.
The demo on the official site is extremely scary, it shows leaking info through an VM on TOR
Looks like everything since sandy bridge until kaby lake is affected.
The demo on the official site is extremely scary, it shows leaking info through an VM on TOR
Last edited:
hoom
Veteran
New Win 10 update has further Spectre related fixes https://support.microsoft.com/en-nz/help/4494441/windows-10-update-kb4494441
So I've been reading a perf hit from ZombiLoad around 3% for desktop and up to 9% for datacenter. Some specific workloads on Mac being hit up to 40%.
Those of us with VPS are being shafted more and more over time as additional fixes are applied by hosts. Maybe Intel should pay for all hosts around the world to bump up all their clients one perf level.
Those of us with VPS are being shafted more and more over time as additional fixes are applied by hosts. Maybe Intel should pay for all hosts around the world to bump up all their clients one perf level.
I haven't followed closely, so can someone gauge the following statement I saw on other forums for truthiness?
- One of the fixes/patches disables HyperThreading thus downgrading i7's to i5's with major financial impact considering the premium Intel charges between the models.
From what I've read so far, ChromeOS is disabling HT in its next update.