Meltdown και Spectre

Συζήτηση στην κατηγορία 'Γενικά' που ξεκίνησε ο χρήστης debianass, 6 Ιαν 2018.

  1. DarkGoth Παιδί για τις δουλειές του Forum

    ολο το hardware εχει «κρυφα λειτουργικα». πως αλλιως θα ρυθμιζεται η λειτουργια του; σχετο το hardware ειναι ενα ματσο καλωδια και τρανζιστορακια. μονα τους δεν μπορουν να συντονιστουν, για να λειτουργησουν «ομαδικα», και να παραγουν αξιοποιησιμο αποτελεσμα. ακομα και αν λειτουργησουν μονα τους, αυτο που θα παραγουν θα ειναι μονο τυχαια αχρηστα δεδομενα (θορυβος). αυτο το «λειτουργικο» ονομαζεται firmware, και υπαρχει σε ολα τα ηλεκτρονικα εξαρτηματα. και η καρτα γραφικων σου το εχει, και η καρτα ηχου σου το εχει, και ο σκληρος σου το εχει, ακομα και η οθονη σου.
  2. Δε θα αντιληφθείς καμία καθυστέρηση στη λειτουργία. Το αντίθετο, θα τρέχει πολύ πιο γρήγορα από ramdisk σε σχέση με το δίσκο. Μόνο κατα την εκκίνηση θα καθυστερεί λίγο. Άλλωστε και το iso περιέχει συμπιεσμένο το fs. Μπορείς βέβαια να επιλέξεις συμπίεση. Με gzip έχεις μεγαλύτερα αρχεία, μικρότερο χρόνο εκκίνησης, με xz το αντίστροφο.
    Αν διαβάσεις το script, η όλη διαδικασία είναι απλή:
    1. Patch-άρει τον kernel
    2. Συμπιέζει το filesystem. Στην εντολή συμπίεσης επιλέγεις συμπιεστή, π.χ.
    Κώδικας:
    sudo mksquashfs /mnt/sda1 01-debian-buster.squashfs -e /mnt/sda1/home/user/01-debian-buster.squashfs /mnt/sda1/boot -comp xz -b 512k -Xbcj x86
    Στο παράδειγμα το σύστημα που τρέχω συμπιέζει τον εαυτό του. Το έχω κάνει mount στο /mnt/sda1 και θα το αποθηκεύσω στο /home/user ως 01-debian-buster.squashfs.
    Τα paths που ακολουθούν την παράμετρο -e είναι οι φάκελοι ή αρχεία που θέλω να εξαιρεθούν.
    Το /mnt/sda1/home/user/01-debian-buster.squashfs είναι το ίδιο το συμπιεσμένο, αν δεν το εξαιρέσω θα εκτελείται ατέρμονα η εντολή.
    Το /mnt/sda1/boot περιέχει τον kernel και τον εκκινητή (extlinux ή grub). Δεν τα χρειάζομαι προφανώς αφού θα εκκινήσω από pachαρισμένο kernel και από άλλο extlinux.
    To /mnt/sda1/var/apt/cache περιέχει τα deb που έχω κατεβάσει και εγκαταστήσει με apt. Μπορώ να κάνω apt-get clean και να μην το συμπεριλάβω στις εξαιρέσεις.
    Η παράμετρος -comp ορίζει τον compressor, στην περίπτωσή μου επιλέγω xz (μεγαλύτερη συμπίεση, όπως στο iso). Θα μπορούσα να επιλέξω gzip.
    Τα υπόλοιπα ορίζουν το εσωτερικό filesystem του συμπιεσμένου.
    Οταν τελειώσει θα έχω στο /home/user το συμπιεσμένο fs μου έτοιμο να το εκκινήσω από το δίσκο, το usb stick ή το iso.

    Στο debian-porteus όπως και στο slackware-porteus εκκινείς από το φάκελο π.χ. /debian-porteus όπου βάζεις τον kernel, το initrd.xz , το initrd.1 (με τους drivers), το vmlinuz και το/τα squashfs. Δίνοντας στο append το cheatcode "changes=/debian-porteus" δημιουργεί (αν δεν υπάρχει) το φάκελο /debian-porteus/changes που περιέχει ένα σύστημα αρχείων το οποίο επικαλύπτει το υπάρχον από το squashfs. Ανα πάσα στιγμή μπορείς να συμπιέσεις το /debian-porteus/changes και να φτιάξεις π.χ. 02-xorg.squashfs, μετά το 03-gnome.squashfs κ.ο.κ.
    Το σύστημα aufs επικαλύπτει το ένα μετά το άλλο με αριθμητική/αλφαβητική σειρά τα συμπιεσμένα και στο τέλος το ασυμπίεστο /debian-porteus/changes.
    Τα συμπιεσμένα δεν αλλοιώνονται. Αν διαγράψεις π.χ. κάποιο αρχείο που υπάρχει στο squashfs, το aufs θα διατηρήσει την πληροφορία της διαγραφής του στο ../changes, αλλά αν εκκινήσεις χωρίς το changes το αρχείο θα επανεμφανιστεί.

    Αν θέλεις τώρα να ενημερώσεις το περιεχόμενο του συμπιεσμένου, το αποσυμπιέζεις με unsquashfs /../myfile.squashfs, κάνεις edit το περιεχόμενο του φακέλου που θα δημιουργηθεί στο ίδιο path με το squashfs και το επανασυμπιέζεις. Τόσο απλά.

    Το script κάνει εγκατάσταση με debootstrap σε κάποιο φάκελο και τα συμπιέζει από κει. Είναι καλύτερα να κάνεις κανονική εγκατάσταση, να δημιουργήσεις χρήστη και να κάνεις login σαν χρήστης τουλάχιστον μια φορά πριν το συμπιέσεις. Σε διαφορετική περίπτωση θα παρουσιαστεί πρόβλημα με τα δικαιώματα χρήστη και θα τρέχεις μόνο σαν root. Ένα πρόβλημα που αντιμετώπισα τόσο στο porteus όσο και στο debiandog και στο νέο slax και μου πήρε αρκετό χρόνο να το λύσω.
  3. Μόλις συνειδητοποίησα ότι η ιδέα σου να τρέχεις το buster από image/iso/squashfs είναι άκυρη, επειδή το testing branch ενημερώνεται καθημερινά. Ναι μεν μπορείς να ενημερώνεις το /../changes ή το persistance αλλά η ενημέρωση της testing είναι ριζική, θα καταλήξεις να πιάνει περισσότερο χώρο από μια κανονική εγκατάσταση.
    Είναι καλύτερα να σταθεροποιήσεις το jessie και να έχεις το buster κανονικά στο δίσκο.
  4. DarkGoth Παιδί για τις δουλειές του Forum

    ναι, το testing θελω και εγω, για να δω και τι διαφορες εχει απο το σαπιο, στη διαχειριση updates, κλπ. αρχικα θα μπει ΣΤΑΝΤΑΡ σε εξομοιωτη, για εγκατασταση / δοκιμη / σετταρισμα. οποτε αναγκαστικα θα μπει σε loopdev. για μετα δεν ξερω πως θα το κανω. εκει μπερδευομαι. τα squashfs ειναι για τυπου portable νομιζω μονο (και το Τινυ με squashfs δουλευει, γι'αυτο αργει λιγο η εκκινηση του, ειδικα σε hybrid mode, που ειναι πιο βαρια). αλλα αυτο καποια στιγμη θα βγει εξω απο τον εξομοιωτη, για μονιμη «bare metal» χρηση. οπως εβγαλα και το σαπιο, οταν πεταξα το αλλο σαπιο (το ουμπουντου). οποτε με squashfs μαλλον δεν βολευει πολυ
  5. asinoro Banned

    Πως τόσοι ερευνητές βρήκαν μια 20 χρονών διαρροή στους επεξεργαστές την ίδια χρονική στιγμή.

    https : / / www . wired . com / story / meltdown-spectre-bug-collision-intel-chip-flaw-discovery

    Καλά και αυτά τα σαΐνια οι προστάτες προμηθευτές αντιικών, τι κάνανε όλα αυτά τα χρόνια;
    Δικιά μου ερώτηση χωρίς απάντηση ή μάλλον την απάντηση την γνωρίζετε.

    STATUS UPDATE -- EDIT DarkGoth:. ποσες φορες σε εχουμε πει να μην διασπειρεις ανυποστατες φημες; ποσες φορες σε εχουμε πει, οχι αμεσα λινκ σε μεσα μαζικης εξημερωσης; (δηθεν και καλα «σατανικες συμπτωσεις» και συνομωσιολογιες για την ανακαλυψη της ευπαθειας; ειμαστε σοβαροι; ). σπαω το λινκ για να μην το πατησει καποιος καταλαθος
  6. Το script του Stephane Lesimple ελέγχει αν το σύστημά μας είναι ευπαθές στα Meltdown και Spectre.
    Το δοκίμασα σε debian και μου έφερε τα αναμενόμενα αποτελέσματα, προφανέστατα κάνει και για ubuntu/mint και όλες τις debian based διανομές.
    Το κατεβάζουμε από το github:
    Κώδικας:
    wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
    και το εκτελούμε ως διαχειριστές με την εντολή:
    Κώδικας:
    sudo sh spectre-meltdown-checker.sh
    Αν δεν τρέξει όπως αναμένεται στη διανομή που χρησιμοποιούμε, μπορούμε να δοκιμάσουμε το script του Jerry Bezencon (product manager του Linux Lite) που βρίσκεται εδώ και λέει ότι κάνει για όλες τις διανομές linux.
    [IMG]
  7. Soulrain Falls Ο Αντμινιστράτορας

    Το ίδιο script τρέχει και ο Jerry, απλά (υποθέτω) προσπάθησε να κάνει λίγο πιο user-friendly τη διαδικασία. Επειδή όμως έχει κάνει δύο λανθασμένες υποθέσεις (ότι lsb-release και xterm υπάρχουν σε όλες τις διανομές), το δικό του script δεν τρέχει σε όλες ως έχει.

    Το αρχικό script τώρα, σε ορισμένες περιπτώσεις δίνει false negatives κι επίσης κάνει overwrite κάποια logs, οπότε προσοχή.
  8. DarkGoth Παιδί για τις δουλειές του Forum

    σε debian σαπιο (8), η, τουλαχιστον στο δικο μου σαπιο, το ενα του jerry δεν τρεχει. το ανοιξα και αντικατεστησα το xterm, με το gnome-terminal που εχω, αλλα και παλι «εσκασε» στο lsb-release (θα μπορουσα να το εγκαταστησω λογικα, αλλα το παρατησα). το αλλο, το «αρχικο» ας πουμε, σε εμενα βγαζει οτι θελει κατι xz-tools lz-tools και κατι τετοια (τα βγαζει στην αρχη οτι λειπουν, οταν παει να ελεγξει τον πυρηνα). βεβαια, παιζει να φταιει, οτι το δικο μου συστημα ειναι ξεγυμνωμενο του κερατα. τεσπα, αφου τα εγκατεστησα και το ξανατρεξα, για το meltdown με εβγαζε unknown και για τους 2 πυρηνες, (και τον κλασσικο και τον liquorix. πληρως αναβαθμισμενοι και οι 2), ακομα και με force enable του table isolation στον bootloader (pti=on). για overwrite logs δεν ειδα
  9. Στον intel του workstation με debian stretch μου έβγαλε:
    [IMG]

    To script ελέγχει κατα πόσο έχεις εγκαταστήσει τα υπάρχοντα patch.
    Στους άλλους επεξεργαστές δεν το έχω τρέξει ακόμα.
  10. DarkGoth Παιδί για τις δουλειές του Forum

    ασχετο, αλλα νομιζω, οτι το ανεφερε και ο itsok καπου πιο πανω για τα ιδια σκριπτακια. γιατι οταν ανοιξα τον κωδικα με φανηκε πολυ «οικειος». τα ιδια εβγαλε και σε εμενα, στα 2 πρωτα CVEταδε (λογικο γιατι δεν υπαρχει ακομα update, ουτε φρεσκο microcode). αλλα στο meltdown, γιατι με εβγαλε unknown, ενω υπαρχουν κανονικα εγκατεστημενα και ηδη ενεργα τα αντιστοιχα updates;
  11. Μήπως επειδή είναι AMD?
  12. DarkGoth Παιδί για τις δουλειές του Forum

    το σκεφτηκα, αλλα και παλι δεν θα επρεπε να γραφει οτι ειναι «not vulnerable»; κατω-κατω οντως εγραφε οτι ειναι συστημα AMD, και οτι εχουν χαρακτηριστει σαν ασφαλη, αλλα και παλι. εκτος αν ειναι μπαγκαρισμενο στο σκριπτακι καπου
  13. Το script ψάχνει να βρει αν έχεις περάσει το patch σε intel. Δεν κάνει penetration test. Θα διανεμηθούν και τέτοια πάντως τα οποία θα δοκιμάζουν σε πραγματικές συνθήκες αν μπορούν να υποκλέψουν την cache του kernel. Προς το παρόν αυτό είναι διαθέσιμο, αν βρούμε κάτι άλλο ενημερώνουμε όπως έκανα παραπάνω ή όπως έκανε ο itsok.

    Στα log files (/var/log) δεν παρατήρησα καμιά διαφορά. Ισως να συμβαίνει μόνο σε arch ή σε συγκεκριμένη έκδοση kernel.
  14. Soulrain Falls Ο Αντμινιστράτορας

    Δε μου έτυχε εμένα, απλά με μπέρδεψε η διατύπωση του issue στο GitHub και διορθώνω: δεν κάνει overwrite κανένα log το script, απλά ελέγχει το output του dmesg, το οποίο μπορεί να γίνει ovewrite από άλλες διεργασίες κι έτσι (στην περίπτωση που αναφέρθηκε) να δώσει ως αποτέλεσμα false positive για το PTI.

    Και η ενδιαφέρουσα ( ; ) πληροφορία της ημέρας: όταν μιλάμε για το Project Zero (στο συγκεκριμένο θέμα), στην πραγματικότητα πρόκειται για έναν και μόνο πιτσιρικά 22 χρονών, ο οποίος διαβάζω είναι φοβερό μυαλό (όχι επειδή εργάζεται στη Γούγλη, ήταν από πριν κι έχει δουλέψει και σε εφαρμογή κρυπτογραφημένων μηνυμάτων ή κάτι τέτοιο). Απ' ό,τι λένε και οι άλλες ομάδες που ανακάλυψαν τις συγκεκριμένες ευπάθειες, αυτός τις βρήκε αρκετά νωρίτερα και μάλιστα μόνος του.
  15. Το διάβασα, χάκεψε το pc του. Πάντως γενικότερα αυτή είναι η πολιτική της google στους προγραμματιστές. Ξεζουμίζει τους καλύτερους, κι αν οι ίδιοι τυγχάνουν υποψιασμένοι και αρνηθούν, αγοράζει τις εταιρίες που δουλεύουν και οικειοποιείται τον κώδικα. Πικρή πείρα...
  16. Soulrain Falls Ο Αντμινιστράτορας

    Όλοι το κάνουν αυτό. Κι αν κάποιος δε γουστάρει, μπορεί πάντα να γίνει freelancer. Οι περισσότεροι γουστάρουν όμως (παρά τους ενδεχόμενους ηθικούς ενδοιασμούς) γιατί τέτοια περιβάλλοντα και τεχνολογίες δεν πρόκειται να δουν αλλιώς με τα μάτια τους. Άλλο είναι να χακεύεις το ραδιόφωνο του παππού κι άλλο να έχεις την ευκαιρία να ξεψαχνίσεις ολόκληρο datacenter, να παίξεις με κβαντικό υπολογιστή ή δεν ξέρω κι εγώ τι.
  17. Μια καλή, ασφαλής και οικονομική εναλλακτική είναι το pinebook64

    [IMG]

    Φοράει arm επεξεργαστή cortex 64 4πύρηνο, τρέχει οποιαδήποτε διανομή linux που υποστηρίζει arm, έχει εσωτερικό δίσκο και κοστίζει $89 με οθόνη 11" και $100 με 14". Μέσα έχει ένα pine64 m/b, σαν το raspberry αλλά καλύτερο και φθηνότερο.
    Δεν το έχω δοκιμάσει αλλά έχω παίξει με ένα rock64 των ίδιων κατασκευαστών και τα σπάει.
    [IMG]

    Εννοείται ότι δεν είναι ευπαθές σε meltdown/spectre.
  18. Έτσι είναι οι περισσότεροι κολακεύονται με το όνομα google. Αλλά στο τέλος σε τρώει το μεγάλο ψάρι, σαν τον Ιωνά.
  19. Ο Linus τα χώνει χοντρά στην intel για τα patches (IBRS-retpolines)

    O Linus Torvalds μεταφέρει μια ιδιαίτερα έντονη συζήτηση, καταφανώς με παράγοντες της intel, στη mail list του linux kernel:
    (η μετάφραση είναι δική μου. Τυχόν εύστοχες παρατηρήσεις-διορθώσεις θα ενσωματωθούν με αναφορα στο διορθωτή)

    Linus (προηγουμένως): Όλα αυτά είναι καθαρά σκουπιδια.
    Αλήθεια, η intel σχεδιάζει να κάνει αυτή τη σκατά-αρχιτεκτονική; Υπάρχει κανείς να τους πει ότι είναι εντελώς παλαβομάρες;
    Παρακαλώ πολύ, αν υπάρχουν τεχνικοί της intel εδώ, να μιλήσουν στους μανατζεραίους τους.

    intel: Αν η εναλλακτική ήταν η ανάκληση δύο δεκαετιών προιόντων και η προμήθεια νέων επεξεργαστών, δεν είναι σίγουρο ότι πρόκειται για παλαβομάρα.

    Linus: Φαίνεται πως το πήρατε σαν αναψυκτικό (cool-aid). Παρακαλώ προσθεστε μια υγιή δόση κριτικής σκέψης. Γιατί, αυτό δεν είναι το είδος του αναψυκτικού που φτιάχνει ένα ευχάριστο τριπάκι με ωραιες εικόνες. Είναι το είδος που σου λιώνει τον εγκέφαλο.

    intel: Ασφαλώς είναι μια απαίσια χακιά, αλλά πρόσεξε: καιγόταν ο κόσμος και στην τελική δε θα μπορούσαμε απλά να κλείσουμε τα datacenters και να επιστρέψουμε στην εκτροφή κατσικιών, έτσι, δεν είναι όλα [τόσο] άσχημα.

    Linus: Δεν είναι απλώς μια απαίσια χακιά. Είναι κάτι πολύ χειρότερο απ'αυτό.

    intel: Σαν μια χακιά για τους υπάρχοντες επεξεργαστές μπορεί να γίνει απλά ανεκτή, αφού θα εξαλειφθεί από την επόμενη γενιά [επεξεργαστών].

    Linus: Εδώ βρίσκεται ένα μέρος του μεγάλου προβλήματος. Το προσωπικο που ελέγχει την υπόθεση δείχνει ότι η intel στην πραγματικότητα φαινεται να σχεδιάζει να κάνει το σωστό για το meltdown (το ερώτημα είναι "πότε;"). Το οποίο δεν αποτελεί καμιά τεράστια έκπληξη, αφού θάπρεπε να είναι εύκολο να διορθωθεί. Είναι σαν να οδηγείς μέσα από μια τεράστια τρύπα. Το να μην κάνει το σωστό για το meltdown θάταν εντελώς απαράδεκτο.
    Έτσι, τα σκουπίδια του IBRS υποδηλώνουν ότι η intel ΔΕΝ σχεδιάζει να κάνει το σωστό στη συγκεκριμένη υπόθεση.
    Ειλικρινά, αυτό είναι εξίσου απαράδεκτο.

    intel: Λοιπόν, το σημείο που είναι αλόκοτο είναι το χαρκατηριστικό IBRS_ALL, το οποίο ένας μελλοντικός επεξεργαστής θα διαφημίζει σαν "είναι δυνατό να μην είναι χαλασμένο". Και μετά θα πρέπει να ρυθμίσεις το IBRS bit μια φορά κατα την εκκίνηση "ζητώντας" του να μην είναι χαλασμένο. Αυτό το σημείο είναι αλόκοτο γιατί θα έπρεπε να έχει αντιμετωπιστεί όπως ακριβώς το RDCL_NO bit, απλά [λέγοντας] "δε χρειάζεται ν'ανησυχείτε πλέον, όλα βαίνουν καλώς".

    Linus: Δεν είναι αυτό το "αλόκοτο". Αυτό είναι αναπόσπαστο μέρος ενός συνολικού "αυτά είναι εντελώς σκουπίδια".
    Ολόκληρο το χαρακτηριστικό IBRS_ALL μου λέει ξεκάθαρα "η intel δε σοβαρολογεί σχετικά μ'αυτό. Εχουμε μια άσχημη χακιά που θα ήταν τόσο δαπανηρή που δε θα ήθελε να την ενεργοποιήσει από προεπιλογή, γιατί θα φανεί άσχημα στις μετρήσεις ταχύτητας(benchmarks)".

    Έτσι, εναλλακτικά, προσπαθούν να ζμπρώξουν το σκουπιδαριό κάτω σ'εμάς. Και το κάνουν εντελώς λάθος, ακόμα και από τεχνικής σκοπιάς.

    Είμαι σίγουρος ότι έχετε εκεί κάποιο δικηγόρο που λέει "θα πρέπει να προχωρήσουμε με κινήσεις που θα μας προστατέψουν νομικά". Αλλά οι νομικίστικες αιτίες δεν έχουν καλά τεχνικά αποτελέσματα, ή καλά patches που θα μπορούσα να εγκαταστήσω.

    intel: Μα χρειάζεται το χαρακτηριστικό IBPB για να ολοκληρώσουμε την προστασία που μας δίνει το retpoline. Ή αυτό ή ξαναφτιάξε όλο το userspace με retpoline.

    Linus: ΠΑΠΑΡΙΑ.

    Μήπως ΚΟΙΤΑΞΑΤΕ τα patches για τα οποία μιλάμε; Θάπρεπε, αφού πολλά από αυτά φέρουν τ'όνομά σας.

    Τα patches κάνουν πράγματα όπως το να προσθέτουν κώδικα του σκουπιδο-MSR στα σημεία εισόδου-εξόδου του πυρήνα. Αυτό είναι παλαβό. Αυτό λέει ότι "προσπαθούμε να προστατεύσουμε τον πυρήνα". Μα έχουμε ήδη retpoline εκεί και με λιγότερη φασαρία.

    Λοιπόν, κάποιος δε λέει την αλήθεια εδώ πέρα. Κάποιος ζμπρώχνει τελείως άχρηστα σκουπίδια με δυσδιάκριτο σκοπό. Λυπάμαι που έπρεπε να το αναδείξω αυτό.

    Αν επρόκειτω για την υποβολή του BRB σε πραγματικά context switches μεταξύ διαφορετικών χρηστών, θα σας πίστευα. Αλλά αυτό δεν είναι επ'όυδενι αυτό που κάνουν τα patches.

    Όπως είναι αυτή τη στιγμή τα patches είναι ΕΝΤΕΛΩΣ ΚΑΙ ΑΠΟΛΥΤΑ ΣΚΟΥΠΙΔΙΑ.

    Κάνουν εντελώς τρελά πράγματα. Πράγματα που δεν βγάζουν νόημα. Αυτό καθιστά όλα σας τα επιχειρήματα αμφισβιτήσιμα και ύποπτα. Τα patches κάνουν πράγματα που δεν είναι φυσιολογικά

    ΤΙ ΣΤΟ ΜΠΟΥΤΣΟ ΣΥΜΒΑΙΝΕΙ ΕΔΩ ΠΕΡΑ;

    Κι εδώ στην πραγματικότητα αγνοείται το πολύ χειρότερο πρόβλημα που μας λέει ότι ολόκληρο το υλικό είναι κυριολεκτικά κακοσχεδιασμένο από ηλίθιους.

    Είναι κακοσχεδιασμένο για δύο κυρίως λόγους:

    1. Ο λόγος που λέει ότι "η intel δεν πρόκειται να το διορθώσει ποτέ".
    Δείτε τις διαφορές ανάμεσα στο IBRS_ALL και στο RDCL_NO. Το ένα λέει ότι η intel θα διορθώσει κάτι. Το άλλο δεν το κάνει.

    Αλήθεια, πιστεύετε ότι αυτό είναι αποδεκτό;

    2. Ο λόγος "δεν υπάρχει κάποιος δείκτης απόδοσης".
    Το νόημα του να έχουμε cpuid και flags από την αρχιτεκτονική του microcode, είναι ότι στηριζομαστε στη χρήση τους για να παίρνουμε αποφάσεις.

    Αλλά εφόσον γνωρίζουμε ότι το κόστος του IBRS είναι ΤΕΡΑΣΤΙΟ για το υπάρχον υλικό, όλα αυτά τα ψηφιακά χαρακτηριστικά είναι απλά εντελώς και απόλυτα σκουπίδια. Κανείς φυσιολογικός δε θα τα χρησιμοποιήσει αφού το κόστος είναι τοσο ψηλό. Έτσι σταματήσατε την προσπάθεια να βρείτε "ποιανού επεξεργαστή εξέλιξη είναι αυτό", ούτως ή άλλως.

    Πιστεύω ότι χρειαζόμαστε κάτι περισσότερο από αυτά τα σκουπίδια.

    Linus.

    H intel σε χθεσινή (23/1/18) ανακοίνωσή της είπε: "Λαμβάνουμε σοβαρά υπόψη το feedback των συνεργατών μας. Βρισκόμαστε σε διαρκή συνεργασία με την κοινότητα linux, συμπεριλαμβανομένου του Linus, ψάχνοντας να βρούμε από κοινού λύσεις".
  20. Ο Linus είπε επίσης ότι δε θα βγεί η τελική έκδοση του πυρήνα 4.15 το επόμενο σαββατοκύριακο όπως είχε ανακοινωθεί. Αντί αυτής θα βγεί η έκδοση RC 9.