K
News Spectre V4 & (Meltdown) V3a: Details und Patches zu neuen CPU-Sicherheitslücken
- Ersteller Jan
- Erstellt am
- Zur News: Spectre V4 & (Meltdown) V3a: Details und Patches zu neuen CPU-Sicherheitslücken
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
hab mal bei Opera " Strict Site Isolation " aktiviert - soll etwas mehr Speicher kosten , aber man kann es ja leicht wieder deaktivieren falls es zu Problemen kommt
chrome://flags/#enable-site-per-process
lautet der Befehl - funktioniert mit Chrome und Opera , einfach in die Adressleiste einfügen und die Einstellung von Deaktiviert auf aktiviert ändern , wenn ich mich recht entsinne ist diese Maßnahme gegen V4 recht wirksam .
https://www.chromium.org/Home/chromium-security/site-isolation
Current Status
In Chrome 63 and later, turning on Site Isolation helps to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques like Spectre/Meltdown. Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.
In addition, Site Isolation also offers more protection against a certain type of web browser security bug, called universal cross-site scripting (UXSS). Security bugs of this form would normally let an attacker bypass the Same Origin Policy within the renderer process, though they don't give the attacker complete control over the process. Site Isolation can help protect sites even when some forms of these UXSS bugs occur.
Known Issues
Site Isolation represents a major architecture change for Chrome, so there are some tradeoffs when enabling it, such as increased memory overhead. The team has worked hard to minimize this overhead and fix as many functional issues as possible. On Chrome for desktop, a few known issues remain:
For users:
chrome://flags/#enable-site-per-process
lautet der Befehl - funktioniert mit Chrome und Opera , einfach in die Adressleiste einfügen und die Einstellung von Deaktiviert auf aktiviert ändern , wenn ich mich recht entsinne ist diese Maßnahme gegen V4 recht wirksam .
https://www.chromium.org/Home/chromium-security/site-isolation
Current Status
In Chrome 63 and later, turning on Site Isolation helps to mitigate attacks that are able to read otherwise inaccessible data within a process, such as speculative side-channel attack techniques like Spectre/Meltdown. Site Isolation reduces the amount of valuable cross-site information in a web page's process, and thus helps limit what an attacker could access.
In addition, Site Isolation also offers more protection against a certain type of web browser security bug, called universal cross-site scripting (UXSS). Security bugs of this form would normally let an attacker bypass the Same Origin Policy within the renderer process, though they don't give the attacker complete control over the process. Site Isolation can help protect sites even when some forms of these UXSS bugs occur.
Known Issues
Site Isolation represents a major architecture change for Chrome, so there are some tradeoffs when enabling it, such as increased memory overhead. The team has worked hard to minimize this overhead and fix as many functional issues as possible. On Chrome for desktop, a few known issues remain:
For users:
- Higher overall memory use in Chrome (about 10-11% in Chrome 67 when isolating all sites with many tabs open).
Zuletzt bearbeitet:
A
Amusens
Gast
*ABO*
Es nimmt ja kein Ende .... Uff
Bin gespannt was es Hardwareseitig alles gefixt ist
Es nimmt ja kein Ende .... Uff
Bin gespannt was es Hardwareseitig alles gefixt ist
K
knoxxi
Gast
Für Spectre-NG: Nr3 Intel Only
Lazy-FP-State-Restore
https://m.heise.de/security/meldung...//www.heise.de/newsticker/&wt_t=1528971760573
Lazy-FP-State-Restore
https://m.heise.de/security/meldung...//www.heise.de/newsticker/&wt_t=1528971760573
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 38.528
A
Amusens
Gast
oh mir sind nur die Infos zu den "alten" Sicherheitslücken bekannt aber nur von AMD ...... das ab Zen+2 es sein wird.!? So Grob mit bekommen.Cool Master schrieb:
Von Intel habe ich noch nichts gelesen ob überhaupt ein Hardware Fix für die alten Sicherheitslücken gibt, in absehbarer Zeit
Cool Master
Fleet Admiral
- Registriert
- Dez. 2005
- Beiträge
- 38.528
Für alle gibt es noch kein fixes Datum aber für die v2 und 3 wird es wohl mit Cascade Lake ein HW-Fix geben.
Siehe:
https://techcrunch.com/2018/03/15/i...s-for-spectre-and-meltdown-on-upcoming-chips/
Siehe:
https://techcrunch.com/2018/03/15/i...s-for-spectre-and-meltdown-on-upcoming-chips/
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
AMD : Spectre
1 über Betriebssytem / Browser
2 über Uefi / Microcode , Zen2 Hardware
3 + 3a nicht betroffen
4a ab Zen 2 Hardware , eigentlich nur ein zusätzliches Bit
https://www.heise.de/ct/ausgabe/201...ie-Sicherheitsluecken-Spectre-NG-4069919.html
AMD spendiert künftigen Prozessoren ein zusätzliches Bit im Machine-Specific Register (MSR) 48h, um SSB abzuschalten. In einem Whitepaper erklärt AMD, wie sich SSB bei bisherigen Prozessoren abschalten lässt.
1 über Betriebssytem / Browser
2 über Uefi / Microcode , Zen2 Hardware
3 + 3a nicht betroffen
4a ab Zen 2 Hardware , eigentlich nur ein zusätzliches Bit
https://www.heise.de/ct/ausgabe/201...ie-Sicherheitsluecken-Spectre-NG-4069919.html
AMD spendiert künftigen Prozessoren ein zusätzliches Bit im Machine-Specific Register (MSR) 48h, um SSB abzuschalten. In einem Whitepaper erklärt AMD, wie sich SSB bei bisherigen Prozessoren abschalten lässt.
A
Amusens
Gast
Okay danke
@Cool Master
Und Danke @MK one
Dann wird nach Zen2 hoffentlich Zen3 komplett ohne Browser/Betreibssystem & Microcode sicher sein.
@Cool Master
Und Danke @MK one
Dann wird nach Zen2 hoffentlich Zen3 komplett ohne Browser/Betreibssystem & Microcode sicher sein.
K
knoxxi
Gast
OpenBSD schaltet per Default Hyper Threading auf Intel Prozessoren ab
https://heise.de/security/meldung/S...//www.heise.de/newsticker/&wt_t=1529497041988
https://heise.de/security/meldung/S...//www.heise.de/newsticker/&wt_t=1529497041988
Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
Heise schreibt aber auch oft ziemlichen Mist:\
Für ein ehemaliges Fachmagazin ist das echt peinlich!
Die meinen sicher nicht MT sondern SMT.
Für ein ehemaliges Fachmagazin ist das echt peinlich!
K
knoxxi
Gast
Klar ist das mit dem MT natürlich Käse, sonst würde das OS nur noch 1 Core nutzen können. 
Aber Heise hat extrem nachgelassen.
Aber Heise hat extrem nachgelassen.
Ja und vergessen hat Heise auch zu erwähnen dass dies nur der erste Schritt ist da OpenBSD SMT auch für andere Hardwarehersteller und Architekturen abschalten will:
"For now this only works on Intel CPUs when running OpenBSD/amd64. But we're planning to extend this feature to CPUs from other vendors and other hardware architectures."
Quelle: https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html
"Security oriented BSD operating system OpenBSD is making the move to disable Hyper Threading (HT) on Intel CPUs and more broadly moving to disable SMT (Simultaneous Multi Threading) on other CPUs too. "
Quelle: https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-Disabling-SMT
"For now this only works on Intel CPUs when running OpenBSD/amd64. But we're planning to extend this feature to CPUs from other vendors and other hardware architectures."
Quelle: https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html
"Security oriented BSD operating system OpenBSD is making the move to disable Hyper Threading (HT) on Intel CPUs and more broadly moving to disable SMT (Simultaneous Multi Threading) on other CPUs too. "
Quelle: https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-Disabling-SMT
A
Amusens
Gast
ist ja recht still .....
Zuletzt bearbeitet von einem Moderator:
(kann kein edit firetv box oeffnet nicht)
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
https://www.heise.de/security/meldu...ert-spekulativen-Buffer-Overflow-4108008.html
und die nächste Lücke .. , diesmal nicht nur lesen im geschützten Speicherbereich , sondern auch schreiben ... , bis jetzt ist nur von Intel und ARM die Rede
und die nächste Lücke .. , diesmal nicht nur lesen im geschützten Speicherbereich , sondern auch schreiben ... , bis jetzt ist nur von Intel und ARM die Rede
Zuletzt bearbeitet:
@MK one -ist ja auch ein Derivat von Meltdown (bzw. ein Spectre/Meltdown "cross-over") laut dem Artikel (siehe pdf bei heise Kapitel 2.3 und im folgenden erläutern sie wie sie die TLB-overload Nutzen um den Angriff auszuführen). Ist eine wichtige Vorraussetzung die Nicht-Prüfung der Berechtigung des abgefragten Prozesses durch die Speculative Execution.
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
https://www.techspot.com/review/1659-intel-spectre-variant-4-performance-test/
When patching Variant 1, 2 and 3 we had found reduced gaming performance on the i7-8700K by up to 5%, though for the most part we saw a 0 to 3% decrease in frame rates. Variant 4 has seen a further 1 to 3% dip, though this time we were testing with the non-K 8700, but the margins should be much the same across the entire range.
In other words, since December the gaming performance of Intel Coffee Lake CPUs is down by 1 to 6%, or about 1-2 fps in games pushing over 60 fps and up to 5 fps for high refresh rate gaming. Definitely not a huge deal overall, but it’s worth keeping in mind that Intel will suffer an IPC hit because of this with future architectures that address these vulnerabilities at the hardware level.
4 - 8 % Leistungsverlust für Intel CPU s bei Verwendung der Spectre 1 - 4 Patches ... = Intel IPC Vorteil gegenüber AMD = Null komma gar nix mehr ....
PS: AMD und Spectre 4 ...
Speculative Store Bypass affects not just Intel but also AMD and ARM. That said, AMD and ARM processors can be fixed via a simple software update, so if you keep your operating system and web browser up to date you’ll be protected against Variant 4 automatically.
When patching Variant 1, 2 and 3 we had found reduced gaming performance on the i7-8700K by up to 5%, though for the most part we saw a 0 to 3% decrease in frame rates. Variant 4 has seen a further 1 to 3% dip, though this time we were testing with the non-K 8700, but the margins should be much the same across the entire range.
In other words, since December the gaming performance of Intel Coffee Lake CPUs is down by 1 to 6%, or about 1-2 fps in games pushing over 60 fps and up to 5 fps for high refresh rate gaming. Definitely not a huge deal overall, but it’s worth keeping in mind that Intel will suffer an IPC hit because of this with future architectures that address these vulnerabilities at the hardware level.
4 - 8 % Leistungsverlust für Intel CPU s bei Verwendung der Spectre 1 - 4 Patches ... = Intel IPC Vorteil gegenüber AMD = Null komma gar nix mehr ....
PS: AMD und Spectre 4 ...
Speculative Store Bypass affects not just Intel but also AMD and ARM. That said, AMD and ARM processors can be fixed via a simple software update, so if you keep your operating system and web browser up to date you’ll be protected against Variant 4 automatically.
Zuletzt bearbeitet:
@MK one :
Ich bezweifle das das was hier als Spectre 1.2 beschrieben wird in der Weise auf AMD funktioniert (bzw. gut genug funktioniert)
1.2 Spectre1.2: Read-only Protection Bypass:
Spectre3.0, aka Meltdown [39], relies on lazy enforcement of User/Supervisor protection flags for page-table entries (PTEs). The same mechanism can also be used to bypass the Read/Write PTE flags.We introduce Spectre1.2, a minor variant of Spectre-v1 which depends on lazy PTE enforcement, similar to Spectre-v3.
Da Meltdown auf AMD CPUs wegen der Überprüfung eines zusätzlichen Bits nicht zum tragen kommt:
Siehe:
Meltdown could be considered a design flaw in the OS, but it was really a team effort between the hardware and software. The Intel hardware does maintain zero-order protection across protection domains, but fails to prevent speculative execution from using protected data to make reliably detectable changes in the cache state. This provides a high-bandwidth covert channel for reading protected data. AMD was right to block this case before execution (since there is no case in which the memory access would be allowed to complete, allowing it to execute speculatively provides no benefits). Ironically, Intel's TSX extensions provide a large increase in the throughput of the Meltdown attack, as well as eliminating the exceptions that could be monitored by the OS.
Frei das Fett markierte übersetzt: " Intel Hardware macht zwar eine grundsätzliche Prüfung über das Überschreiten von Schutz-Domänen (Stichwort Ring0, 1 usw) aber lässt speculative Exekution geschützter Daten zu die nachweisbare Veränderungen der Caches zustände auslösen...
Dies erlaubt einen hoch-bandbreitigen verdeckten Kanal zum Daten auslesen.
AMD hat Recht gehabt diesen Fall vor der Ausführung zu blocken (da es keinen einzigen Fall gibt in welchem ein erlaubter Speicherzugriff abgeschlossen sein könnte, würde auch die Erlaubnis diesen Spekulativ auszuführen keinen Vorteil haben). Ironischerweise erlauben Intels TSX Erweiterungen einen hohe Steigerung im Durchsatz der Meltdown attacke...
Weiter unten führt er dann nochmal genauer aus:
"The Meltdown exploit requires that (1) the user process page tables include the kernel page tables, and (2) speculative memory accesses from user space to kernel pages are allowed to execute (returning data to the core and allowing dependent speculative instructions to execute using the *value* loaded from the kernel address).
This can be fixed by changing either (1) or (2). AMD prohibits (2), by refraining from executing loads speculatively if the code is currently operating in user space and the Page Table Entry for the target address has the kernel attribute set. Contrary to some comments, this is not hard to detect -- it requires comparing one bit of the current processor execution mode and one bit from the Page Table Entry that had to be present to perform the address translation and access checking for the memory reference. "
Frei übersetzt:
Meltdown verlangt (1) dass eine User Prozess Page Table die Kernel Pages tables enthält und (2) den Spekulative Speicherzugriff aus dem User space auf Kernel Seiten erlaubt zur Ausführung sind (also das zurückbringen von Datem aus dem Kern und das Erlauben davon abhängiger spekulativer Befehle unter Benutzung des Wertes der aus der Kernel Adresse geladen wird).
Dies kann verhindert/gefixed werden entweder durch Veränderung der Bedingung (1) oder (2).
AMD verbietet Fall (2) - spekulative Loads werden an der Ausführung gehindert/zurückgehalten FALLS der Code der gerade in Ausführung ist im User Space operiert UND der Page Table Eintrag für die Adresse das Kernel attribut trägt.
Im Gegenteil zu manchen Kommentaren ist dies nicht schwer zu prüfen. Es erfordert nur die Prüfung eines Bits des aktuellen CPU Ausführungs Modes mit einem Bit aus dem Page Table Eintrag welcher VORHANDEN SEIN MUSS für die Adress Übersetzung und die Zugriffsprüung für die Speicher-Referenz.
Da oben von "The same mechanism..." gesprochen wird gehe ich davon aus das Intel hier mal wieder nicht die Berechtigungs-Bits prüft....
Spectre 1.2 wird wohl also dann nur Intel und manche ARM CPUs treffen - wie Meltdown (=Spectre v3 bei den Autoren dieses Papers).
EDIT: Weiter unten wird McAlpin noch deutlicher:
"The speculative read is a good optimization feature -- unless it can be proven that it can never be successful! This is the benefit of the AMD implementation. The core knows what mode it is operating in (user or kernel), and the Page Table Entry has a bit that says that user-mode access is not allowed. Since the core needs to read the Page Table Entry to get the Physical Address, it is guaranteed that this information is available to the core before the L1 Data Cache tags can be queried. I would say that there is not much excuse for speculatively executing the read in this case. "
Frei übersetzt: Der Spekulative Read ist ein Gutes Optimierungsfeature - sofern man nicht belegen kann dass er nie erfolgreich sein wird ! Dies ist der Vorteil der AMD Implementierung. Der Kern weiss in welchem Modus er operiert (User oder Kernel) und der Page Tabel Eintrag hat ein Bit dass sagt user-mode Zugriff ist verboten. Da der Kern den Page Tabel Eintrag lesen muss um die Physikalische Adresse zu erhalten ist eigentlich garantiert dass diese Information der CPU verfügbar ist BEVOR diese den L1 Data cache abfrägt. Ich würde sagen es gibt eigentlich keine Entschuldigung dafür solche Befehle dennoch Spekulativ Auszuführen.
Ich bezweifle das das was hier als Spectre 1.2 beschrieben wird in der Weise auf AMD funktioniert (bzw. gut genug funktioniert)
1.2 Spectre1.2: Read-only Protection Bypass:
Spectre3.0, aka Meltdown [39], relies on lazy enforcement of User/Supervisor protection flags for page-table entries (PTEs). The same mechanism can also be used to bypass the Read/Write PTE flags.We introduce Spectre1.2, a minor variant of Spectre-v1 which depends on lazy PTE enforcement, similar to Spectre-v3.
Da Meltdown auf AMD CPUs wegen der Überprüfung eines zusätzlichen Bits nicht zum tragen kommt:
Siehe:
Meltdown could be considered a design flaw in the OS, but it was really a team effort between the hardware and software. The Intel hardware does maintain zero-order protection across protection domains, but fails to prevent speculative execution from using protected data to make reliably detectable changes in the cache state. This provides a high-bandwidth covert channel for reading protected data. AMD was right to block this case before execution (since there is no case in which the memory access would be allowed to complete, allowing it to execute speculatively provides no benefits). Ironically, Intel's TSX extensions provide a large increase in the throughput of the Meltdown attack, as well as eliminating the exceptions that could be monitored by the OS.
Frei das Fett markierte übersetzt: " Intel Hardware macht zwar eine grundsätzliche Prüfung über das Überschreiten von Schutz-Domänen (Stichwort Ring0, 1 usw) aber lässt speculative Exekution geschützter Daten zu die nachweisbare Veränderungen der Caches zustände auslösen...
Dies erlaubt einen hoch-bandbreitigen verdeckten Kanal zum Daten auslesen.
AMD hat Recht gehabt diesen Fall vor der Ausführung zu blocken (da es keinen einzigen Fall gibt in welchem ein erlaubter Speicherzugriff abgeschlossen sein könnte, würde auch die Erlaubnis diesen Spekulativ auszuführen keinen Vorteil haben). Ironischerweise erlauben Intels TSX Erweiterungen einen hohe Steigerung im Durchsatz der Meltdown attacke...
Weiter unten führt er dann nochmal genauer aus:
"The Meltdown exploit requires that (1) the user process page tables include the kernel page tables, and (2) speculative memory accesses from user space to kernel pages are allowed to execute (returning data to the core and allowing dependent speculative instructions to execute using the *value* loaded from the kernel address).
This can be fixed by changing either (1) or (2). AMD prohibits (2), by refraining from executing loads speculatively if the code is currently operating in user space and the Page Table Entry for the target address has the kernel attribute set. Contrary to some comments, this is not hard to detect -- it requires comparing one bit of the current processor execution mode and one bit from the Page Table Entry that had to be present to perform the address translation and access checking for the memory reference. "
Frei übersetzt:
Meltdown verlangt (1) dass eine User Prozess Page Table die Kernel Pages tables enthält und (2) den Spekulative Speicherzugriff aus dem User space auf Kernel Seiten erlaubt zur Ausführung sind (also das zurückbringen von Datem aus dem Kern und das Erlauben davon abhängiger spekulativer Befehle unter Benutzung des Wertes der aus der Kernel Adresse geladen wird).
Dies kann verhindert/gefixed werden entweder durch Veränderung der Bedingung (1) oder (2).
AMD verbietet Fall (2) - spekulative Loads werden an der Ausführung gehindert/zurückgehalten FALLS der Code der gerade in Ausführung ist im User Space operiert UND der Page Table Eintrag für die Adresse das Kernel attribut trägt.
Im Gegenteil zu manchen Kommentaren ist dies nicht schwer zu prüfen. Es erfordert nur die Prüfung eines Bits des aktuellen CPU Ausführungs Modes mit einem Bit aus dem Page Table Eintrag welcher VORHANDEN SEIN MUSS für die Adress Übersetzung und die Zugriffsprüung für die Speicher-Referenz.
Da oben von "The same mechanism..." gesprochen wird gehe ich davon aus das Intel hier mal wieder nicht die Berechtigungs-Bits prüft....
Spectre 1.2 wird wohl also dann nur Intel und manche ARM CPUs treffen - wie Meltdown (=Spectre v3 bei den Autoren dieses Papers).
EDIT: Weiter unten wird McAlpin noch deutlicher:
"The speculative read is a good optimization feature -- unless it can be proven that it can never be successful! This is the benefit of the AMD implementation. The core knows what mode it is operating in (user or kernel), and the Page Table Entry has a bit that says that user-mode access is not allowed. Since the core needs to read the Page Table Entry to get the Physical Address, it is guaranteed that this information is available to the core before the L1 Data Cache tags can be queried. I would say that there is not much excuse for speculatively executing the read in this case. "
Frei übersetzt: Der Spekulative Read ist ein Gutes Optimierungsfeature - sofern man nicht belegen kann dass er nie erfolgreich sein wird ! Dies ist der Vorteil der AMD Implementierung. Der Kern weiss in welchem Modus er operiert (User oder Kernel) und der Page Tabel Eintrag hat ein Bit dass sagt user-mode Zugriff ist verboten. Da der Kern den Page Tabel Eintrag lesen muss um die Physikalische Adresse zu erhalten ist eigentlich garantiert dass diese Information der CPU verfügbar ist BEVOR diese den L1 Data cache abfrägt. Ich würde sagen es gibt eigentlich keine Entschuldigung dafür solche Befehle dennoch Spekulativ Auszuführen.
Zuletzt bearbeitet:
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
@Iscaran
gehe ich auch von aus , AMD hat es , allgemein gesprochen , einfacher , weil sie nicht zugunsten der Performance bei den Protection/Berechtigungs Bits des öfteren auf deren Abfrage verzichtet haben
Man sieht es an Spectre V4 = aktuelles OS + Browser = geschützt , während bei Intel zusätzlich ein Firmware Update nötig ist .
Der kommende Hardware Schutz gegen V4 besteht bei AMD aus einem zusätzliches Bit in einem Register ...
aber selbst wenn Intel Patches rausbringt , einige von ihnen müssen manuell aktiviert werden , weil sie Performance kosten , könnte ja sonst auffallen ....
es fehlen ja immer noch ein paar Spectre NG Lücken , würde mich nicht wundern wenn ne Intel CPU mit allen ( aktivierten ) Patches dann 6 - 10 Prozent an Leistung verliert ...
gehe ich auch von aus , AMD hat es , allgemein gesprochen , einfacher , weil sie nicht zugunsten der Performance bei den Protection/Berechtigungs Bits des öfteren auf deren Abfrage verzichtet haben
Man sieht es an Spectre V4 = aktuelles OS + Browser = geschützt , während bei Intel zusätzlich ein Firmware Update nötig ist .
Der kommende Hardware Schutz gegen V4 besteht bei AMD aus einem zusätzliches Bit in einem Register ...
aber selbst wenn Intel Patches rausbringt , einige von ihnen müssen manuell aktiviert werden , weil sie Performance kosten , könnte ja sonst auffallen ....
es fehlen ja immer noch ein paar Spectre NG Lücken , würde mich nicht wundern wenn ne Intel CPU mit allen ( aktivierten ) Patches dann 6 - 10 Prozent an Leistung verliert ...
Nein das Bit ist ja schon da und wird (zumindest war dass die Aussage eines Developers auf dem Intel blog) schon seit jeher geprüft. Was die Immunität gegen Meltdown darstellt.
Die anderen Store Bypass geschichten ist AMD wohl zumindest im Prinzip anfällig weshalb sie den zusätlichen Store Bypass Disable bit "optional" setzen. Siehe Whitepaper
Ich gehe davon aus dass es sich dabei um das Verhindern von user space - user space store bypass attacken handelt. Denn die anderen dürften eigentlich eh nischt stattfinden.
Und ob user space zu user space noch kritisch ist ? => Deswegen das "optionale" Bit zum Abschalten des Schutzes ?
Allerdings bin ich mir bzgl. der Implikationen hier nicht wirklich sicher.
Mal gespannt wann die restlichen Spectre-NG Lücken kommen.
Eigentlich müsste 1 Davon ja SGX-Pectre sein...: http://web.cse.ohio-state.edu/~zhang.834/papers/SgxPectre.pdf
Der ist so ähnlich wie der SMM-Spectre wenn ich das richtig lese/verstehe: https://blog.eclypsium.com/2018/05/17/system-management-mode-speculative-execution-attacks/
Die anderen Store Bypass geschichten ist AMD wohl zumindest im Prinzip anfällig weshalb sie den zusätlichen Store Bypass Disable bit "optional" setzen. Siehe Whitepaper
Ich gehe davon aus dass es sich dabei um das Verhindern von user space - user space store bypass attacken handelt. Denn die anderen dürften eigentlich eh nischt stattfinden.
Und ob user space zu user space noch kritisch ist ? => Deswegen das "optionale" Bit zum Abschalten des Schutzes ?
Allerdings bin ich mir bzgl. der Implikationen hier nicht wirklich sicher.
Mal gespannt wann die restlichen Spectre-NG Lücken kommen.
Eigentlich müsste 1 Davon ja SGX-Pectre sein...: http://web.cse.ohio-state.edu/~zhang.834/papers/SgxPectre.pdf
Der ist so ähnlich wie der SMM-Spectre wenn ich das richtig lese/verstehe: https://blog.eclypsium.com/2018/05/17/system-management-mode-speculative-execution-attacks/
