Ny sårbarhet upptäckt i Intel CPU'er: Zombieload

Tyvärr är det väl lite så när man tjänar mycket (Mycket vill oftast ha mer) på bekostnad av andra saker. Om dom skulle lösa dessa så skulle dom få göra om rätt så mycket i sin konstruktion runt CPUer skulle jag misstänkta och då lär deras CPUer inte bli billigare iaf.

Imo är detta https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a... en större nyhet, och ett säkerhetshål som antagligen kommer drabba betydligt fler.

Varför är inte AMD påverkad av detta då de också använder Hyperthreading?.
Eller är det bara det att man inte har testat att samma attack även fungerar på AMD?

Inga av intel-datorerna i huset har HT så jag känner mig lugn

Varför är inte AMD påverkad av detta då de också använder Hyperthreading?.
Eller är det bara det att man inte har testat att samma attack även fungerar på AMD?

Inga av intel-datorerna i huset har HT så jag känner mig lugn

Varför är inte AMD påverkad av detta då de också använder Hyperthreading?.
Eller är det bara det att man inte har testat att samma attack även fungerar på AMD?

Inga av intel-datorerna i huset har HT så jag känner mig lugn

Jag hittar fortfarande inte vart Intel rekommenderar att man ska stänga av HT. Dom skriver ju snarare att dom inte rekommenderar det?!

Skickades från m.sweclockers.com

COUNTERMEASURES
As ZombieLoad leaks loaded values across logical cores, a straightforward mitigation is disabling the use of hyperthreading. Hyperthreading improves performance for certain workloads by 30 % to
40 % [8, 52], and as such disabling it may incur an unacceptable
performance impact.

Co-Scheduling.
Depending on the workload, a more efficient
mitigation is the use of co-scheduling [55]. Co-scheduling can be
configured to prevent the execution of code from different protection domains on a hyperthread pair. Current topology-aware
co-scheduling algorithms [64] are not concerned with preventing
kernel code from running concurrently with user-space code. With
such a scheduling strategy, leaks between user processes can be prevented but leaks between kernel and user space cannot. To prevent
leakage between kernel and user space, the kernel must additionally ensure that kernel entries on one logical core force the sibling
logical core into the kernel as well. This discussion applies in an
analogous way to hypervisors and virtual machines.

Flushing Buffers.
We have demonstrated that ZombieLoad
also works across protection boundaries on a single logical core.
Hence, disabling hyperthreading or co-scheduling are not fully effective as mitigation. We have not found an instruction sequence
that reliably prevents leakage across protection boundaries. Even
flushing the entire L1 data cache (using MSR_IA32_FLUSH_CMD) and
issuing as many dummy loads as there are fill-buffer entries (“load
stuffing”) is not sufficient. There is still remaining leakage, which
we assume is caused by the replacement policy of the line-fill buffer.
Hence, to fully mitigate the leakage, we require a microcode update
which provides a method to flush the line-fill buffer.

Selective Feature Deactivation.
Weaker countermeasures target individual building blocks (cf. Section 5). The operating system
kernel can make sure always to set the accessed and dirty bits in
page tables to impair Variant 2. Unfortunately, Variant 1 is always
possible, if the attacker can identify an alias mapping of any accessible user page in the kernel. This is especially true if the attacker
ZombieLoad: Cross-Privilege-Boundary Data Sampling
is running in or can create a virtual machine. Hence, we also recommend disabling VT-x on systems that do not need to run virtual
machines.

Removing Prefetch Gadgets.
To prevent targeted data leakage,
prefetch gadgets need to be neutralized, e.g., using array_index_nospec
in the Linux kernel. This function clamps array indices into valid
values and prevents arbitrary virtual memory to be prefetched.
Placing these functions is currently a manual task and due to the
incomplete documentation of how Intel CPUs prefetch data, these
mitigations cannot be complete. Note that Spectre mitigations using
lfence instructions might also be incomplete against ZombieLoad.
Another way to prevent prefetch gadgets from reaching sensitive
data is to prevent this data from being mapped in the address
space of the prefetch gadget. Exclusive Page-Frame Ownership [39]
(XPFO) partially achieves this for the Linux kernel’s mapping of
physical memory. Prefetch gadgets can also be neutralized using Speculative Load
Hardening [10] (SLH). SLH prevents speculative execution by introducing artificial data dependencies via a compiler pass. SLH incurs
a performance overhead of 10 % to 50 % for typical applications. To
the best of our knowledge, its overhead for kernel or hypervisor
code has not been studied yet.

Instruction Filtering.
The above discussion mostly focusses
on attacks across process or virtual-machine boundaries. For attacks
inside of a single process (e.g., JavaScript sandbox), the sandbox
implementation must make sure that the requirements for mounting
ZombieLoad are not met. One example is to prevent the generation
and execution of the clflush instructions, which so far is a crucial
part of the attack.

Secret Sharing.
On the software side, we can also rely on secret
sharing techniques used to protect against physical side-channel
attacks [65]. We can ensure that a secret is never directly loaded
from memory but instead only combined in registers before being
used. As a consequence, observing the data of a load does not reveal
the secret. For a successful attack, an attacker has to leak all shares
of the secret. This mitigation is, of course, incomplete if register
values are written to and subsequently loaded from memory as part
of context switching.