x86_64 bug (X86_BUG_CPU_INSECURE)

[tommybertsen]

πριν 4 λεπτά, το μέλος alexcrx έγραψε:

ρε σεις δεν φτιαχνουμε και εμεις ενα intel flaw????????

να βγαζει το σημα του lab ξερω γω και να λεει ποιος???????????????

να βγαινει ο @astrolabos μετα και να λεει αυτος 1-0 και να βγαζει καπνους απο το usb.............

το patch θα ριχνει τις επιδοσεις μονο 70% οταν θα εχεις γνησια windows....................

συγνωμη για τις λαλακιες που λεω και ελπιζω να γελασετε

Εγώ αναρωτιέμαι κάτι άλλο. 

Πόσος κόσμος έχει ΠΡΑΓΜΑΤΙΚΑ επηρεαστεί από όλα αυτά τα bugs?

[Matia]

Τόσοι, 1-0

[DEADLAZARUS]

Χρησιμοποιώ τη skroutz security και νιώθω ασφαλής. Στην πράξη δεν επηρεάζεται ο μέσος χρήστης, αλλά, όπως και να το κάνουμε, πολλά τα security bugs.

[minast]

14 hours ago, tommybertsen said:

Εγώ αναρωτιέμαι κάτι άλλο. 

Πόσος κόσμος έχει ΠΡΑΓΜΑΤΙΚΑ επηρεαστεί από όλα αυτά τα bugs?

Πρακτικά όλος ο κόσμος που δεν έχει dedicated server για τα πράγματα που κάνει. Ακόμη και το lab πχ αν τρέχει σε μηχάνημα που δεν είναι αποκλειστικά δικό του, δεν έχεις τρόπο να ξέρεις αν κάποιος τρέχει κώδικα στο διπλανό thread που διαβάζει τα δεδομένα σου.

Δεν υπολογίζω καν όλους τους τελικούς χρήστες για το φυσικό PC που έχουν στο σπίτι τους, ή τους διαχειριστές υποδομών που είναι η δουλειά τους - όλοι μας ζούμε πλέον και στο cloud. Πολλές από τις υπηρεσίες που χρησιμοποιούμε πρέπει να μακροπρόθεσμα να διασφαλιστούν απέναντι σε τέτοιες ευπάθειες...

[tommybertsen]

πριν 9 ώρες, το μέλος minast έγραψε:

Δεν υπολογίζω καν όλους τους τελικούς χρήστες για το φυσικό PC που έχουν στο σπίτι τους

Πολύ γενικά τα παραπάνω. Επηρεάστηκε κανείς; Αριθμούς, αποδείξεις, whatever. Δεν βλέπω να επηρεάστηκε ο μέσος/κοινός χρήστης. 

Και όταν λέμε μακροπρόθεσμα, τι εννοούμε; Οι ευπάθειες υπάρχουν από το 1800 και απλά βγήκαν τώρα στη φόρα, σε πόσα χρόνια θα φανεί η "ζημιά" ;

[acct]

Όταν κυκλοφόρησαν τα νέα για τα πρώτα exploits ήμουν από εκείνους που συνιστούσαν υπομονή, για να τα αξιολογήσουμε στην πραγματική τους έκταση. Πλέον, αισθάνομαι ότι η έκταση είναι τόσο μεγάλη, που τελικά θα είναι δύσκολο να υπολογιστεί.

 

Αν και η φύση των ευπαθειών δεν είναι καθόλου ίδια, η κατάσταση μου θυμίζει την εποχή που αναρωτιόμασταν πόσους επηρεάζει πραγματικά η υπονόμευση του RSA. Εφόσον φαίνεται πια ότι μιλάμε για μια τεράστια οικογένεια ομοειδών προβλημάτων, δεν έχουμε αποτελεσματικό τρόπο να ξέρουμε πόσον καιρό πριν και σε ποιους ήταν γνωστοί οι τρόποι αξιοποίησής τους. Αυτό υποσκάπτει την αξιοπιστία των πληροφοριών που έχουν διακινηθεί από όλα τα επηρεαζόμενα συστήματα σχεδόν από τη δημιουργία τους μέχρι σήμερα.

 

Επιπλέον, είναι αναποτελεσματικό και ασύμφορο να μπαλωθούν οι τρύπες σε παλιότερες αρχιτεκτονικές. Και τα μπαλώματα, όπου υπάρξουν, αναγκαστικά θα είναι χονδροειδή, για να αντιμετωπιστούν οι δομικές αβλεψίες.

 

Για τους περισσότερους από εμάς μεμονωμένα, το διακύβευμα είναι σχετικά μικρό, ίσως αμελητέο. Σωρευτικά, όμως, το πλήγμα στην αξιοπιστία των υπολογιστικών υποδομών είναι μεγάλο.

[minast]

4 hours ago, tommybertsen said:

Πολύ γενικά τα παραπάνω. Επηρεάστηκε κανείς; Αριθμούς, αποδείξεις, whatever. Δεν βλέπω να επηρεάστηκε ο μέσος/κοινός χρήστης. 

Και όταν λέμε μακροπρόθεσμα, τι εννοούμε; Οι ευπάθειες υπάρχουν από το 1800 και απλά βγήκαν τώρα στη φόρα, σε πόσα χρόνια θα φανεί η "ζημιά" ;

Δυστυχώς (ή ευτυχώς) η ασφάλεια δεν δουλεύει έτσι. Πέρα από αυτούς που χρησιμοποιούν τις ευπάθειες για να προκαλέσουν εμφανείς ζημιές, είναι και αυτοί που τις αξιοποιούν αφανώς. Γι' αυτό πχ σταμάτησε ο περισσότερος κόσμος να χρησιμοποιεί τις προεπιλεγμένες ρυθμίσεις elliptic curve που πρότεινε η NSA, γι' αυτό πατσάραμε ή πετάξαμε τα διάτρητα σπιτικά ρουτεράκια που ήταν επί χρόνια ορθάνοιχτα χωρίς να το γνωρίζει κανείς, κλπ.

Εξάλλου, οι στοχευμένες περιπτώσεις παραβίασης, συνήθως γίνονται αντιληπτές όταν είναι πλέον αργά, και πολλές φορές δεν είναι μόνο μία η μέθοδος... Η τρύπα speculative / out-of-order execution είναι πολύ προβληματική γιατί αυξάνει σημαντικά την έκθεση σε κατά τα άλλα ασφαλή συστήματα, χωρίς να αφήνει ιδιαίτερα ίχνη, επομένως δύσκολα θα ακούσουμε ότι στο meltdown οφείλεται η τάδε παραβίαση. Ευτυχώς αυτά που είναι πολύ εύκολα αξιοποιήσιμα έχουν περιοριστεί.

 

Θα παραφράσω μία φράση του Bruce Lee λέγοντας ότι περισσότερο από αυτόν που θα χακέψει μία φορά δέκα χιλιάδες υπολογιστές, φοβάμαι αυτόν που θα χακέψει έναν υπολογιστή δέκα χιλιάδες φορές...

[Eddie]

NetSpectre Vulnerability hits the web

[ARMAGEDDON]

https://www.theregister.co.uk/2018/08/14/intel_l1_terminal_fault_bugs/

[yanni]

3 minutes ago, ARMAGEDDON said:

https://www.theregister.co.uk/2018/08/14/intel_l1_terminal_fault_bugs/

 

Θα δούμε κανέναν νέας σχεδίασης επεξεργαστή από την Intel το 2020 με χαμηλότερο IPC από Skylake και θα γελάμε.  

[ARMAGEDDON]

έχει καταντήσει απλά γελοίο !
κάθε βδομάδα όλο και κάτι να βγαίνει και απλά δεν κάνουν τίποτα ουσιαστικά

μου ήθελαν να ασχοληθούν και με άλλα πράματα εκεί στην INTEL , αντί να έχουν στα συρτάρια όπως όλοι περιμέναμε έτοιμα σχέδια κλπ κλπ για δύο - τρεις γενιές μπροστά !

απλά κινήσεις πανικού +2cores να προσθέτουν

[Jaco]

Αυτό δεν φαίνεται να επηρεάζει τόσο πολύ, αλλά αθροιστικά όλα στο τέλος θα πρέπει να κλείσει το SMT η intel και να τελειώνουμε.

 

https://www.phoronix.com/scan.php?page=article&item=l1tf-early-look&num=1

[Jaco]

Benchmarksμε τα νέα patches. Τελικά για server environment στα intel πρέπει να κλείνουν το SMT. 

 

 

https://www.phoronix.com/scan.php?page=article&item=l1tf-foreshadow-xeon&num=1

[GriGaS]

Μιας και έχω χάσει λίγο τη μπάλα, οι coffee lake επηρεάζονται από όλα αυτα;

[minast]

2 hours ago, GriGaS said:

Μιας και έχω χάσει λίγο τη μπάλα, οι coffee lake επηρεάζονται από όλα αυτα;

Ναι, αλλά είναι και από τους πρώτους για τους οποίους βγαίνει microcode κάθε φορά...

[Jaco]

Για όσους τρέχουν linux αυτό είναι ένα script για να δουν αν το σύστημά τους είναι πατσαρισμένο σωστά για spectre/meltdown/L1TF.

 

https://github.com/speed47/spectre-meltdown-checker/

 

Για να το τρέξετε:

git clone https://github.com/speed47/spectre-meltdown-checker/
cd spectre-meltdown-checker
sudo ./spectre-meltdown-checker.sh 

Αν είναι σωστά πατσαρισμένο θα δείτε κάτι παρόμοιο (αυτό είναι από τον 1950X)
 

Spoiler

Checking for vulnerabilities on current system
Kernel is Linux 4.18.3-041803-generic #201808180530 SMP Sat Aug 18 09:32:58 UTC 2018 x86_64
CPU is AMD Ryzen Threadripper 1950X 16-Core Processor

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates IBRS capability:  NO
    * CPU indicates preferring IBRS always-on:  NO
    * CPU indicates preferring IBRS over retpoline:  NO
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO
    * CPU indicates IBPB capability:  NO
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO
    * CPU indicates STIBP capability:  NO
    * CPU indicates preferring STIBP always-on:  NO
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  YES  (AMD non-architectural MSR)
  * L1 data cache invalidation
    * FLUSH_CMD MSR is available:  NO
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO
  * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):  NO
  * CPU microcode is known to cause stability problems:  NO  (model 0x1 family 0x17 stepping 0x1 ucode 0x8001129 cpuid 0x800f11)
  * CPU microcode is the latest known available version:  UNKNOWN  (latest microcode version of your CPU is not known to this script)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to Variant 1:  YES
  * Vulnerable to Variant 2:  YES
  * Vulnerable to Variant 3:  NO
  * Vulnerable to Variant 3a:  NO
  * Vulnerable to Variant 4:  YES
  * Vulnerable to Variant l1tf:  NO

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec:  YES  (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch:  NO
* Kernel has mask_nospec64 (arm64):  NO
> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (Mitigation: Full AMD retpoline)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES
    * IBRS enabled and active:  NO
  * Kernel is compiled with IBPB support:  YES
    * IBPB enabled and active:  NO
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO
  * Kernel compiled with retpoline option:  YES
    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
> STATUS:  NOT VULNERABLE  (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (Not affected)
* Kernel supports Page Table Isolation (PTI):  YES
  * PTI enabled and active:  NO
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  YES
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface:  YES  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
> STATUS:  NOT VULNERABLE  (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
* Mitigated according to the /sys interface:  YES  (Not affected)
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

 

Έγινε επεξεργασία Αύγουστος 21, 2018 από Jaco

[Jaco]

Η πικρή αλήθεια για την intel. Με τα νέα security patches σε κάποια benchmarks μέχρι 20% κάτω οι Xeon ενώ οι EPYC μόνο 1-2% (στο ίδιο bench). Και κάπως έτσι μπορεί να δεις μια επένδυση εκατοντάδων χιλιάδων να χάνει ακόμα και το 20% της αξίας της σε ένα update, το οποίο εγείρει αλλά ερωτήματα, όπως αν θα κάνουν όλοι τα απαιτούμενα updates ή θα ρισκάρουν την ασφάλεια των δεδομένων τους (ακόμα και προσωπικών δικών μας), ώστε να μειώσουν το κόστος της ζημιάς.

 

Στο server κομμάτι έφαγε μεγάλη σφαλιάρα η intel.

 

https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=1

Έγινε επεξεργασία Αύγουστος 30, 2018 από Jaco

[Eddie]

Intel Fixes Yet Another Flaw In Management Engine

 

Οσα πάντως δεν δωθούν με windows update ,  σε μητρικές 2+ ετών δεν βλέπω να τα παίρνουνε ποτέ, αφου ετσι και αλλιως συνεχεια θα βγαινουνε καινουρια.

 

Για hardware fix για desktop cpus απο q4/19 και να δουμε πάλι αν θα ναι για ολα.

Έγινε επεξεργασία Σεπτέμβριος 17, 2018 από Eddie

[jefm]

Μου φαίνεται παράλογο να δώσω χρήματα για επεξεργαστή που ξέρω ότι έχει πρόβλημα, ακόμα και οι λύσεις που δίνονται με πτώση της απόδοσης είναι απαράδεκτες για καινούργιους, ευτυχώς ο γέρο 2600k αντέχει ακόμα και έχει μεν πρόβλημα αλλά έχει κάνει και απόσβεση τόσα χρόνια.  Σε άλλα προιόντα θα είχε γίνει χαμός, θα υπήρχαν αποζημιώσεις ή αντικαταστάσεις, φανταστείτε ένα αυτοκίνητο που για κάποιο λόγο να πρέπει να πέσει η ιπποδύναμη κατά 20%.

[minast]

2 hours ago, jefm said:

Μου φαίνεται παράλογο να δώσω χρήματα για επεξεργαστή που ξέρω ότι έχει πρόβλημα, ακόμα και οι λύσεις που δίνονται με πτώση της απόδοσης είναι απαράδεκτες για καινούργιους, ευτυχώς ο γέρο 2600k αντέχει ακόμα και έχει μεν πρόβλημα αλλά έχει κάνει και απόσβεση τόσα χρόνια.  Σε άλλα προιόντα θα είχε γίνει χαμός, θα υπήρχαν αποζημιώσεις ή αντικαταστάσεις, φανταστείτε ένα αυτοκίνητο που για κάποιο λόγο να πρέπει να πέσει η ιπποδύναμη κατά 20%.

Η τελευταία σύγκριση είναι μάλλον υπερβολική, θα το σύγκρινα περισσότερο με το θέμα της VW, όπου υποχρεώθηκε να αλλάξει προγραμματισμό εγκεφάλου μετά το σκάνδαλο των καυσαερίων, αυξάνοντας κατανάλωση και χάνοντας απόδοση. Δεν είναι μία καθολική ποσοστιαία μείωση, αλλά γίνεται αρκετά αισθητή υπό προϋποθέσεις. Αντίστοιχα, στα περισσότερα μέρη του πλανήτη δεν δόθηκαν ποτέ αποζημιώσεις στους καταναλωτές...

Δυστυχώς στους επεξεργαστές δεν είναι πρόβλημα που λύνεται εύκολα. Νέες γενιές επεξεργαστών χειρίζονται καλύτερα τα ίδια θέματα ασφαλείας (της AMD ακόμη περισσότερο), αλλά μακροπρόθεσμα πρέπει να αλλάξει ουσιαστικά ο σχεδιασμός, αφού αυτά βασίζονται στον τρόπο που κερδίζαμε "τσάμπα" ταχύτητα τόσα χρόνια.