Jump to content

x86_64 bug (X86_BUG_CPU_INSECURE)


Recommended Posts

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

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

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

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

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

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

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

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

Link to post
Share on other sites
  • Replies 433
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Άνοιξα ξεχωριστό θέμα για το X86_BUG_CPU_INSECURE που φαίνεται για την ώρα να επηρεάζει μόνο τους Intel και τους ARM, αλλά όχι τους AMD.   Περιγραφή: Το bug αυτό οφείλεται στο ότι ο επε

To μηχάνημα που χρησιμοποιήθηκε για τις μετρήσεις παρακάτω είναι ένα Dell Precision 5520 με Intel Xeon 1505 v6, 32GB RAM, 1TB 960PRO, Nvidia 2200M graphics. Έτρεξα τα τεστ. Πέρασα το windows upda

πριν και μετά το update : atto, as ssd & anvil's benchmark  super pi & aida64 ram benchmark cinebench, cpu-z, vray benchmark as ssd                      πρίν         

Posted Images

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

Link to post
Share on other sites
14 hours ago, tommybertsen said:

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

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

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

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

  • Like 2
  • Thanks 1
Link to post
Share on other sites
πριν 9 ώρες, το μέλος minast έγραψε:

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

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

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

Link to post
Share on other sites

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

 

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

 

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

 

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

  • Like 1
Link to post
Share on other sites
4 hours ago, tommybertsen said:

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

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

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

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

 

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

  • Like 1
Link to post
Share on other sites
  • 2 weeks later...
  • 3 weeks later...

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

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

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

  • Haha 1
Link to post
Share on other sites
2 hours ago, GriGaS said:

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

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

Link to post
Share on other sites

Για όσους τρέχουν 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

 

Edited by Jaco
Link to post
Share on other sites
  • 2 weeks later...

Η πικρή αλήθεια για την 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

Edited by Jaco
  • Like 4
Link to post
Share on other sites
  • 3 weeks later...

Intel Fixes Yet Another Flaw In Management Engine

 

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

 

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

Edited by Eddie
  • Like 2
Link to post
Share on other sites

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

Link to post
Share on other sites
2 hours ago, jefm said:

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

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

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.