Új hozzászólás Aktív témák
-
S_x96x_S
őstag
REDHAT ... SOLUTION IN PROGRESS - még elemzés alatt - frissítés várható ...
"TLBleed - side-channel attack over shared TLBs"
https://access.redhat.com/solutions/3508581"Resolution
Red Hat Product Security has rated this update as having a security impact of Moderate.
All Red Hat products are being evaluated for impact and Red Hat will issue updates as soon as they are available. Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as errata are available.Mitigations
Short term mitigations can be split into the following two categories:- Prevent attacker code from running on co-resident hyperthreads. This can be performed by following (and providing) industry standard guidance, which has always been not to share hyperthreads between two unrelated containers, or VMs. For use cases where customers do not provide direct local system access but do run user containers or VMs, this may be sufficient.
- In the case of untrusted local users on the same underlying physical or virtual system, it may be necessary to further tune thread pinning, or even to disable Intel Hyper-Threading.There are two primary recommended methods of disabling Hyper-Threading on the Red Hat Enterprise Linux platforms.
- Disable at the BIOS level.
- Disable the CPUs via the sysfs tunables.
"INTEL
"In the Intel case, a unified non-inclusive L2 TLB is used to provide additional translations and will also be searched for translations. The Intel design uses an associative cache type design for the individual TLB entries with a computable replacement algorithm, that is similar to the one used in other caches, in which virtual addresses are hashed (and XORed) to generate the TLB entry that will be used to lookup a translation. Such an associative design is more easily exploited because an attacker on one thread can predetermine which virtual memory address (VA) accesses on the sibling thread will displace shared entries with the co-resident attacker thread, thus they are able to infer through monitoring evictions of TLB entries to which they have access which other VA entries are used by the sibling thread.
"AMD
"
Other microprocessors implement their data side TLBs differently. For example, AMD utilizes a “fully associative” dTLB structure in which translations can be allocated into any entry within the shared TLB resource. This makes such side-channel analysis much more complex, because the replacement algorithm is not a simple hashing function but instead can allocate into any entry. Thus, the background noise from other memory translations interferes significantly. At this time, the TLBleed author has been unable to reproduce the Intel Hyper-Threading attack against the AMD implementation in the EPYC processor.
"[ Szerkesztve ]
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
> Fel van fújva az egész, 6-8 éve is sebezhetőek voltak ezek a procik,
szerintem inkább alul vannak kezelve ...
régebben csak egy szük kör tudott ezekről a problémákról, manapság már mindenki.hardveres fix kellene.
Speculating about speculation: on the (lack of) security guarantees of Spectre-V1 mitigations
https://www.sigarch.org/speculating-about-speculation-on-the-lack-of-security-guarantees-of-spectre-v1-mitigations/Mottó: "A verseny jó!"
Új hozzászólás Aktív témák
ph Információk szerint a TLBleed biztonsági rés van a háttérben, ami az Intel egyes CPU-in használható ki.
