CPU Security Flaws MELTDOWN and SPECTRE

Does anybody know which CPU generation PCID and INVPCID were introduced? Those are the things needed to reduce the hit of the an KPTI implementation.
 
hoom said:
The AMD guy is pretty adamant.
His suggested code is literally IF Vendor ID != AMD THEN Force 'CPU Insecure mode'
Click to expand...

Perhaps so, though perhaps the full reasoning is not yet open or hasn't overcome the level about approval.

The description of why it doesn't need the isolation feature is curious.
"The AMD microarchitecture does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

It's one thing to say lesser privilege modes cannot access higher privilege data, say at all, but the next qualifier about page faults seems like it requires knowing that there is a fault before the page data that would generate the fault is available.

Is there a scenario where an access from low to high privilege that cannot generate a fault?
Does the broad set of patches for the isolation feature include remedies for additional side-channel attacks besides the three cited for Intel, since wholly different ISAs appear to have benefit from avoiding side-channel timing attacks as well?
 
rcf said:
Which Intel CPU generations are affected by this?
Click to expand...
Potentially most of them, although the broadness of the checks may be to hide the full range. Some of the proof of concept work in the papers over the last year or so included Nehalem and Sandy Bridge. TSX attacks are limited to Haswell and beyond.
Skylake was mentioned and I think vulnerable in some tests, though my recollection covers an attack not covered by KAISER that it was immune to.

This is potentially broader than Intel (Via?), since ARM64 is getting a similar change. The architectural reason may come down to a choice of how the TLB caches are updated and when checks for validity and permissions are handled.
If it's the timing attack issues only, from a systemic point of view, what vulnerable processors are doing may not be wrong in a conventional sense. The architectures do not require constant time for valid actions to be taken or finalized, and there's a tension between doing things as quickly as possible and hiding details about the workload that affect how quickly they can be done. Cryptographic functions will actively de-optimize or stall in cases where going too fast would hint at the content of what they are processing, for example.
 
There's a bunch of threads this has come up, and one already focused on it in the PC industry subforum.
Of note, this isn't Intel-only, as page table isolation or architectural proposals have shown up for ARM64 and RISC-V, respectively.
It's curious what AMD in particular may be doing differently, possibly in a gray area in the architectural spec.
Some ISAs have an architectural separation of user and kernel memory, which the patches are trying to emulate for an apparently important but undisclosed reason.
 
Some of the (unverified, not really explained) rumors seem to be pointing to the page table isolation changes that were proposed for side-channel exploits might be coincidentally fixing some other more direct exploit, by virtue of separating user and kernel spaces.
In the public sphere, there's been some poking around but no confirmed result of being able to get data to escape from the bounds of an access that has not fully had a permission fault handled.
That would be a more direct flaw, but is this more universal since there are ARM64 changes (odd if the same bug was done by almost everyone), or are those other isolation patches just along for the ride?

An access should be quashed if it faults, and it seems like a more fundamental hardware issue if it carries over a range of rather distinct architectures even within Intel. Possibly a system call with a valid access, then a forwarding action via store queue to an eventually faulting instruction? That fault should stop a register update, unless there's a fear of the handler being compromised, or possibly it's an error not captured by when subsequent operations in the pipeline are discarded? The pipeline should handle any register dependences, so snaking a temporarily forwarded value shouldn't matter unless the ROB or its equivalent lost track.
An operation that is able to get a forward of that invalidly forwarded data that doesn't get quashed? A swap/copy to a valid location that doesn't fault, and that is forwarded? Is there a mild fault condition that would let the process continue on its way?
 
firstminion said:
Page faults may not be required, is AMD CPU really immune to this?
Click to expand...
Maybe?
The statement from AMD is that it would not allow references, speculative or not, from a lower privilege level to a higher one if it would generate a fault.
Depending on the scenario, it may be that a speculative access' page fault does not get processed if some other condition flushes the instruction, like a mispredict or other invalidation.
If no request is generated, then maybe the activity with the cache that is being massaged doesn't occur?

The sparseness of detail being what it is, one worse scenario is that this is a different bug.
 
Now the even nastier part: they did mention ARM.
So, which core fucks the pooch as much as Intel currently does?
The choice is endless.
 
That might depend on whether the fixes being deployed on the various architectures cover the same set of issues. There may be a set of more general issues that apply to most, and if the furor is accurate possibly more critical exploits that apply to a subset.
 
Intel released a response
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Click to expand...
 
If it's a side-channel attack based on cache/buffer timings, it is true that the processors are working as designed. That portion didn't ruffle many feathers earlier, for some reason.

Some people are claiming arbitrary read access, rather than inferring kernel address layout, which is something additional that wouldn't fit that description.
None so far claim the ability to modify data, although reading the right system data could enable a destructive write, or if skimming credentials/keys be damaging enough on its own.
 
The thing I do not get the most is the glee I hear. "I will never buy Intel again", "Intel was cheating all the time", etc.
Mistakes happen to anyone. There is no way of proving that there are no hidden issues in AMD CPUs (at the very least, IMHO, no practical way).
And, well, I do actually expect Intel CPUs to be validated more thoroughly (purely because Intel has more resources).

Also, in case nobody saw, the kernel developers' opinion of this specific mistake is quite clear:
Several people including Linus requested to change the KAISER name.

We came up with a list of technically correct acronyms:
User Address Space Separation, prefix uass_

Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

but we are politically correct people so we settled for

Kernel Page Table Isolation, prefix kpti_

Linus, your call :)
Click to expand...
 
You must log in or register to reply here.
Back
Top