έγραψε:Implementing UEFI Secure Boot in Fedora
Υλοποιώντας την ασφαλή εκκίνηση κατά UEFI στη FedoraMay. 30th, 2012 11:11 pm
30 Μαΐου 2012, 11:11 μμ[personal profile] mjg59
Προσωπικό προφίλ mjg59Edit 16:17EDT 31/5/12: Clarification of who gets the $99
Διόρθωση 16:17EDT 31/5/12: Διευκρίνηση όσον αφορά το ποιός εισπράττει τα 99 δολάριαEdit 02:10EDT 01/6/12: Clarification that it's a one-off payment
Διόρθωση 02:10EDT 01/6/12: Διευκρινίζοντας πως πρόκειται για «άπαξ» -μία κι έξω δηλαδή- πληρωμή(Brief disclaimer - while I work for Red Hat, I'm only going to be talking about Fedora here. Anything written below represents only my opinions and my work on Fedora, not Red Hat's opinions or future plans)
Σύντομη αποποίηση ευθυνών - αφού εργάζομαι για τη Red Hat, θα μιλήσω εδώ μόνο για τη Fedora. Ό,τι είναι γραμμένο παρακάτω, αντιπροσωπεύει μόνο τις απόψεις μου και την εργασία μου στη Fedora, όχι τη γνώμη της Red Hat ή μελλοντικά σχέδια)Fedora 17 was released this week. It's both useful and free, and serves as a welcome addition to any family gathering. Do give it a go. But it's also noteworthy for another reason - it's the last Fedora release in the pre-UEFI secure boot era. Fedora 18 will be released at around the same time as Windows 8, and as previously discussed all Windows 8 hardware will be shipping with secure boot enabled by default. While Microsoft have modified their original position and all x86 Windows machines will be required to have a firmware option to disable this or to permit users to enrol their own keys, it's not really an option to force all our users to play with hard to find firmware settings before they can run Fedora. We've been working on a plan for dealing with this. It's not ideal, but of all the approaches we've examined we feel that this one offers the best balance between letting users install Fedora while still permitting user freedom.
Η Fedora 17 κυκλοφόρησε αυτή την εβδομάδα. Είναι και χρήσιμη και ελεύθερη, ενώ αποτελεί και μια ευπρόσδεκτη προσθήκη σε οποιαδήποτε οικογενειακή συγκέντρωση. 
εδώ δεν καταλαβαίνω τι θέλει να πει ο ποιητής Δοκιμάστε την. είναι όμως άξια αναφοράς για ακόμα έναν λόγο. - είναι η τελευταία έκδοση της Fedora στην προ-UEFI secure boot εποχή. Η Fedora 18 δα κυκλοφορήσει περίπου τον ίδιο καιρό με τα Windows 8 και όπως έχει ήδη συζητηθεί, όλα τα μηχανήματα με Windows 8 θα αποστέλλονται με ενεργοποιημένο από προεπιλογή το secure boot. Ενώ η Microsoft τροποποίησε την αρχική θέση της και όλα τα X86 Windows μηχανήματα θα απαιτείται να έχουν μια επιλογή στο firmware είτε για να απενεργοποιείται είτε για να επιτρέπεται να εγγράφει ο χρήστης τα δικά του κλειδιά, το να αναγκάζουμε όλους τους χρήστες μας να παίζουν με δύσκολες στην εύρεση ρυθμίσεις firmware προτού να είναι σε θέση να τρέξουν τη Fedora δεν είναι επιλογή. Δουλέψαμε επάνω σε ένα σχέδιο ώστε να το αντιμετωπίσουμε αυτό. Δεν είναι το ιδανικό, αλλά από όλες τις μεθόδους προσέγγισης που εξετάσαμε πιστεύουμε πως αυτή προσφέρει τη μεγαλύτερη ισορρόπηση μεταξύ της παροχής στους χρήστες της ικανότητας να εγκαταστήσουν τη Fedora ενώ διασφαλίζοντας την ελευθερία του χρήστη. Άρα, το συγκεκριμένο θέμα πρώτον έχει να κάνει μόνο με τη δυνατότητα dual-booting με Windows 8, καθώς για όποιον δεν χρειάζεται καθόλου windows, υπάρχει η επιλογή να απενεργοποιήσει το secure boot και να βάλει ότι θέλει, αφού μόνο τα windows 8 το χρειάζονται. Ούτε καν δηλαδή, αφού το όλο θέμα περιγράφεται ως μια παροχή όχι σε όσους θέλουν απλά να κάνουν dual-boot με win 8 και Fedora, αλλά σε όσους θέλουν να το κάνουν χωρίς καν να χρειάζεται να μπλεχτούν με ρυθμίσεις στο Bios. Εδώ να σημειώσω στον αγαπητό Matthew Garrett, πως μπροστά στο να χρησιμοποιείς τη Fedora, οι ρυθμίσεις του Bios δεν είναι και τίποτα...
Getting the machine booted
- Εκκινώντας το μηχάνημαMost hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key[1].
Η πλειοψηφία του υλικού που θα είσαστε σε θέση να αγοράσετε κατά το τέλος του χρόνου, θα είναι πιστοποιημένη για Windows 8. Αυτό σημαίνει, πως θα φέρει ένα σύνολο κλειδιών secure boot και αν έρχεται με προεγκαταστημένα Windows 8 τότε το secure boot θα είναι ενεργοποιημένο από προεπιλογή. Αυτό το σύνολο κλειδιών δεν είναι απολύτως σταθερό και θα διαφέρει μεταξύ κατασκευαστών, αλλά οτιδήποττε με το λογότυπο των Windows θα φέρει το κλειδί της Microsoft [1]. We explored the possibility of producing a Fedora key and encouraging hardware vendors to incorporate it, but turned it down for a couple of reasons. First, while we had a surprisingly positive response from the vendors, there was no realistic chance that we could get all of them to carry it. That would mean going back to the bad old days of scouring compatibility lists before buying hardware, and that's fundamentally user-hostile. Secondly, it would put Fedora in a privileged position. As one of the larger distributions, we have more opportunity to talk to hardware manufacturers than most distributions do. Systems with a Fedora key would boot Fedora fine, but would they boot Mandriva? Arch? Mint? Mepis? Adopting a distribution-specific key and encouraging hardware companies to adopt it would have been hostile to other distributions. We want to compete on merit, not because we have better links to OEMs.
Διερευνήσαμε την πιθανότητα να παράξουμε ένα κλειδί της Fedora και να ενθαρρύνουμε τους προμηθευτές υλικού να το ενσωματώσουν, αλλά το απορρίψαμε για δύο λόγους. Πρώτον, ενώ είχαμε μια σε βαθμό έκπληξης θετική ανταπόκριση από τους προμηθευτές, δεν υπήρχε ρεαλιστική πιθανότητα να μπορέσουμε να πείσουμε τους πάντες να το υιοθετήσουν. Αυτό θα σήμαινε πισωγύρισμα στις παλιές κακές μέρες που διαλέγαμε από λίστες συμβατότητας προτού αγοράσουμε υλικό και αυτό είναι θεμελιωδώς εχθρικό προς το χρήστη. Δεύτερον, αυτό θα έβαζε τη Fedora σε μια προνομιούχο θέση. Ως μία από τις μεγαλύτερες διανομές, έχουμε περισσότερες ευκαιρίες να μιλάμε με κατασκευαστές υλικού από ότι έχουν οι περισσότερες άλλες διανομές. Τα συστήματα με το κλειδί της Fedora θα εκκινούσαν σωστά με τη Fedora, αλλά θα εκκινούσαν με Mandriva; με Arch; με Mint; μήπως με Mepis; η υιοθέτηση ενός κλειδιού ειδικού για μια διανομή και η ενθάρρυνση προς τους κατασκευαστές να το χρησιμοποιούν, θα ήταν εχθρική για τις άλλες διανομές. Θέλουμε να συναγωνιζόμαστε με την αξία μαςκαι όχι επειδή έχουμε καλύτερες διασυνδέσεις με τους OEM.Δεν νομίζω πως κάποιος μπορεί να διαφωνήσει με κανένα από τα δύο επιχειρήματα. Το πρώτο είναι κατανοητό, το δεύτερο απλά λέει πως μπορεί η Red hat, η Canonical και η Novell να έχουν τη δυνατότητα (ίσως) να βάλουν δικά τους κλειδιά, αλλά όλες οι άλλες διανομές όχι.An alternative was producing some sort of overall Linux key. It turns out that this is also difficult, since it would mean finding an entity who was willing to take responsibility for managing signing or key distribution. That means having the ability to keep the root key absolutely secure and perform adequate validation of people asking for signing. That's expensive. Like millions of dollars expensive. It would also take a lot of time to set up, and that's not really time we had. And, finally, nobody was jumping at the opportunity to volunteer. So no generic Linux key.
Μια εναλλακτική λύση ήταν να δημιουργηθεί κάτι σαν ένα γενικό κλειδί Linux. Αποδείχτηκε πως και αυτό είναι εξίσου δύσκολο, μιας και θα σήμαινε το να βρεθεί μια οντότητα πρόθυμη να αναλάβει την ευθύνη για τη διαχείριση των κλειδιών για τις διανομές. Αυτό σημαίνει να έχει τη δυνατότητα να κρατά το βασικό κλειδί απολύτως ασφαλές και να διεξάγει τις απαραίτητες επικυρώσεις ατόμων που θα ζητούσαν για υπογραφή. (Με απλά λόγια, να υπάρχει ένας οργανισμός του Linux που αν εγώ πάω με μια διανομή και ζητήσω να έχω το Linux κλειδί για τη διανομή μου, αυτός να μπορεί να με ελέγχει επαρκώς ώστε να διασφαλιστεί πως το Linux κλειδί θα βρεθεί σε υπεύθυνα χέρια και να αναλάβει και την ευθύνη γι αυτό, καθώς σε περίπτωση που εγώ θα εκμεταλλευόμουν το Linux κλειδί μου για να βάλω ένα malware στο Bios, οι μηνύσεις από τη Microsoft θα έπεφταν βροχή). Αυτό είναι ακριβό. Σαν να λέμε εκατομμύρια δολάρια ακριβό. Επίσης, θα έπαιρνε αρκετό χρόνο για να στηθεί και δεν είναι να πεις πως έχουμε και πολύ χρόνο. Και στην τελική, κανένας δεν έτρεξε να γίνει εθελοντής. Οπότε, κλειδί Linux γιοκ.The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their
sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key.
Η τελευταία επιλογή δεν ήταν και πολύ ελκυστική, πιθανότατα όμως είναι η λιγότερο κακή. Η Microsoft θα προσφέρει υπηρεσίες υπογραφής μέσω του portal τους των sysdev. Δεν είναι εντελώς δωρεάν (υπάρχει μια «εφ' άπαξ» αμοιβή των 99$ για να αποκτηθεί πρόσβαση διόρθωση: Τα 99$ πάνε στη Verisign, όχι στη Microsoft - περαιτέρω διόρθωση: αφού πληρώσεις μια φορά, μπορείς να υπογράψεις όσα binaries θέλεις), αλλά είναι φτηνότερο από οποιαδήποτε άλλη ρεαλιστική εναλλακτική θα μπορούσε να υπάρξει. Διασφαλίζει τη συμβατότητα με την ευρύτερη δυνατή γκάμα υλικού και αποφεύγει το να δίνει στη Fedora ειδικά προνόμια έναντι των άλλων διανομών Linux.(Με την έννοια πως τα 99$ για ένα τέτοιο κλειδί είναι ποσό που θα μπορούσε να πληρώσει ακόμα και μια κοινοτική διανομή). Αν υπάρχουν καλύτερες επιλογές, εμείς απλά δεν τις βρήκαμε. Οπότε, κατά πάσα πιθανότητα, αυτή είναι η προσέγγιση που θα ακολουθήσουμε. Το πρώτο στάδιο του bootloader μας (αυτό δηλαδή που γράφεται στο MBR του δίσκου) θα υπογράφεται με ένα κλειδί της Microsoft.Bootloaders
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
Αποφασίσαμε να ακολουθήσουμε μια πολυδιάστατη προσέγγιση όσον αφορά την υπογραφή μας για έναν αρκετά απλό λόγο. Η υπογραφή μέσω της υπηρεσία υπογραφών της Microsoft, είναι χειροκίνητη διαδικασία και αυτό είναι μπελάς. Δεν θέλουμε να έχουμε καθυστερήσεις στις ενημερώσεις του bootloader γιατί κάποιος θα χρειάζεται να βρει μια κόπια του Internet Explorer και μια smartcard και να χτίζει πακέτα με το χέρι. Αντιθέτως, γράφουμε έναν πολύ απλό bootloader[2]. Αυτός δεν θα κάνει τίποτα άλλο από το να φορτώνει έναν αληθινό bootloader (τον grub 2), να πιστοποιεί πως αυτός είναι υπογεγραμμένος με ένα κλειδί υπογραφής της Fedora και τότε να τον εκτελεί. Χρησιμοποιώντας εκεί το κλειδί υπογραφής της Fedora, σημαίνει πως μπορούμε να χτίζουμε ενημερώσεις του grub στην υπάρχουσα υποδομή μας και να τις υπογράφουμε μόνοι μας. Ο bootloader 1ου σταδίου θα αλλάζει σπάνια και δεν προβλέπουμε την αναβάθμισή του περισσότερες από μια φορά ανά κύκλο έκδοσης. Λογικά δεν θα είναι και τόσο βάρος για τη διαχείριση της κυκλοφορίας των εκδόσεων.What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Τί περί του grub; Έχουμε ήδη περάσει στην Fedora 18 στη χρήση του grub2 ως προεπιλογή στα συστήματα EFI, αλλά χρειάζεται ακόμα δουλειά προτού να είναι έτοιμος για το secure boot. Το πρώτο πράγμα είναι το ότι θα απενεργοποιήσουμε το φόρτωμα των modules. Αυτή τη στιγμή μπορείς να φορτώσεις αυθαίρετα κώδικα στον gtrub2 τη στιγμή της εκκίνησης και αυτό καταργεί το νόημα του secure boot. Οπότε, αυτό θα απενεργοποιηθεί. Μετά, θα προσθέσουμε υποστήριξη για την πιστοποίηση πως ο πυρήνας που θα εκκινήσει, είναι υπογεγραμμένος με ένα κλειδί εμπιστοσύνης. Και τελικά θα «αποστειρώσουμε» τη γραμμή εντολών του πυρήνα για να αποφύγουμε κάποια κομμάτια λειτουργικότητας τα οποία θα επέτρεπαν την εκκίνηση αυθαίρετου κώδικα. Όλοι αυτοί οι περιορισμοί θα εξαφανιστούν αν απενεργοποιηθεί το secure boot. Kernel
ΠυρήναςSecure boot is built on the idea that all code that can touch the hardware directly is trusted, and any untrusted code must go through the trusted code. This can be circumvented if users can execute arbitrary code in the kernel. So, we'll be moving to requiring signed kernel modules and locking down certain aspects of kernel functionality. The most obvious example is that it won't be possible to access PCI regions directly from userspace, which means all graphics cards will need kernel drivers. Userspace modesetting will be a thing of the past. Again, disabling secure boot will disable these restrictions.
Το secure boot είναι χτισμένο γύρω από την ιδέα πως ο κώδικας που μπορεί να αγγίξει απευθείας το hardware είναι έμπιστος και κάθε μη έμπιστος κώδικας πρέπει να περνά μέσα από τον έμπιστο κώδικα. Αυτό μπορεί να παρακαμφθεί αν οι χρήστες μπορούν να εκτελούν αυθαίρετα κώδικα στον πυρήνα. Οπότε, θα κινηθούμε προς την απαίτηση υπογεγραμμένων modules για τον πυρήνα και το κλείδωμα κάποιων μορφών λειτουργικότητας του πυρήνα.Το πιο προφανές παράδειγμα, είναι πως δεν θα είναι δυνατή η πρόσβαση των περιοχών του PCI απευθείας από το χώρο του χρήστη, κάτι το οποίο σημαίνει πως όλες οι κάρτες γραφικών θα χρειάζονται οδηγούς στον πυρήνα. Η ρύθμιση λειτουργίας από το χώρο του χρήστη θα είναι παρελθόν. Ξανά, η απενεργοποίηση του secure boot αθ απενεργοποιήσει όλους αυτούς τους περιορισμούς.Signed modules are obviously troubling from a user perspective. We'll be signing all the drivers that we ship, but what about out of tree drivers? We don't have a good answer for that yet. As before, we don't want any kind of solution that works for us but doesn't work for other distributions. Fedora-only or Ubuntu-only drivers are the last thing anyone wants, and this really needs to be handled in a cross-distribution way.
Τα υπογεγραμμένα modules πιθανώς προβληματίζουν από την οπτική γωνία του χρήστη. Θα υπογράφουμε όλους τους drivers που θα διανέμουμε, αλλά τι γίνεται με τους drivers εκτός των αποθετηρίων; Δεν έχουμε ακόμα μια καλή απάντηση γι αυτό. Όπως και πριν, δεν θέλουμε μια λύση που να δουλεύει για εμάς αλλά όχι για άλλες διανομές. Οδηγοί μόνο για Fedora ή μόνο για Ubuntu είναι το τελευταίο πράγμα που θέλει κανείς και αυτό όντως πρέπει να χειριστεί με έναν τρόπο που να περιλαμβάνει όλες τις διανομές.Wait signed what
Για περίμενε, υπογεγραμμένο τί;Secure boot is designed to protect against malware code running before the operating system. This isn't a hypothetical threat. Pre-boot malware exists in the wild, and some of it is nastier than you expect. So obviously bootloaders need to be signed, since otherwise you'd just replace the signed bootloader with an unsigned one that installed malware and booted your OS.
Το secure boot έχει σχεδιαστεί με σκοπό μα προστατεύει από malware κώδικα που εκτελείται πριν το λειτουργικό σύστημα. Αυτό δεν είναι μια υποθετική απειλή. Το Pre-boot malware υπάρχει εκεί έξω και κάποια από αυτά είναι πιο άσχημα από όσο νομίζετε. Οπότε, προφανώς οι bootloaders χρειάζεται να υπογράφονται, αφού αλλιώς απλά θα αντικαθιστούσατε τον υπογεγραμμένο bootloader με έναν μη υπογεγραμμένο ο οποίος θα εγκαθιστούσε κακόβουλο λογισμικό και μετά θα εκκινούσε το λειτουργικό σας σύστημα.But what about the kernel? The kernel is just code. If I take a signed Linux bootloader and then use it to boot something that looks like an unsigned Linux kernel, I've instead potentially just booted a piece of malware. And if that malware can attack Windows then the signed Linux bootloader is no longer just a signed Linux bootloader, it's a signed Windows malware launcher and that's the kind of thing that results in that bootloader being added to the list of blacklisted binaries and suddenly your signed Linux bootloader isn't even a signed Linux bootloader. So kernels need to be signed.
Σχετικά όμως με τον πυρήνα; Ο πυρήνας είναι απλά κώδικας. Αν πάρω έναν υπογεγραμμένο Linux bootloader και μετά τον χρησιμοποιήσω για να εκκινήσω κάτι που μοιάζει με μη υπογεγραμμένο πυρήνα Linux, πιθανώς αντί του πυρήνα εκκίνησα ένα κομμάτι malware. Και αν αυτό το malware μπορεί να επιτεθεί στα windows, τότε ο υπογεγραμμένος Linux bootloader δεν είναι απλά ένας υπογεγραμμένος Linux bootloader, είναι ένας υπογεγραμμένος εκκινητής Windows malware και αυτό είναι που οδηγεί στο αποτέλεσμα αυτός ο bootloader να προστεθεί στη μαύρη λίστα εκτελέσιμων και ξαφνικά ο υπογεγραμμένος Linux bootloader δεν είναι καν υπογεγραμμένος Linux bootloader. Οπότε, οι πυρήνες πρέπει να υπογράφονται. And modules? Again, modules are just code. It's a little trickier, but if your signed kernel loads an unsigned module then that unsigned module can set up a fake UEFI environment and chain into a compromised OS bootloader. Now the attacker just has to include a signed kernel and a minimal initramfs that loads their malware module. It'd slow down boot by a couple of seconds, but other than that it'd be undetectable. X? If you can access the registers on a GPU then you can get the GPU to DMA over the kernel and execute arbitrary code. Trickier again, but still achievable - and if you've locked down every other avenue of attack, it's even attractive.
Και τα modules; Ξανά, τα modules είναι απλά κώδικας. Είναι λίγο πιο περίπλοκο, αλλά αν ο υπογεγραμμένος πυρήνας σας φορτώσει ένα μη υπογεγραμμένο module μετά αυτό το μη υπογεγραμμένο module μπορεί να στήσει ένα ψεύτικο περιβάλλον UEFI και συνδεθεί σε έναν παραβιασμένο bootloader. Τώρα, ο επιτιθέμενος απλά πρέπει να περιλάβει έναν υπογεγραμμένο πυρήνα και ένα βασικό initramfs που φορτώνει το κακόβουλο module. Θα καθυστερούσε την εκκίνηση κάνα δύο δευτερόλεπτα, αλλά πέρα από αυτό δεν θα ήταν ανιχνεύσιμο. Χ; Αν μπορείτε να έχετε πρόσβαση στους καταχωρητές μιας GPU, τότε μπορείτε να κάνετε την GPU να έχει απευθείας πρόσβαση στη μνήμη πάνω από τον πυρήνα και να εκτελέσει αυθαίρετα κώδικα. Πιο δύσκολο, αλλά ακόμα επιτεύξιμο - και αν έχεις κλειδώσει κάθε άλλη λεωφόρο επίθεσης, ακόμα και ελκυστικό.Αν κάνω και κανένα λάθος στις ορολογίες μη βαράτε, δεν είμαι προγραμματιστής, πείτε το να το διορθώσω. 
If we produce signed code that can be used to attack other operating systems then those other operating systems are justified in blacklisting us. That doesn't seem like a good outcome.
Αν παράξουμε κώδικα που μπορεί να χρησιμοποιηθεί για την επίθεση σε άλλα λειτουργικά συστήματα, τότε αυτά τα λειτουργικά συστήματα θα έχουν κάθε δίκιο να μας βάλουν στη μαύρη λίστα. Αυτό δεν μοιάζει καλό αποτέλεσμα.Customisation
- ΠαραμετροποίησηA lot of our users want to build their own kernels. Some even want to build their own distributions. Signing our bootloader and kernel is an impediment to that. We'll be providing all the tools we use for signing our binaries, but for obvious reasons we can't hand out our keys. There's three approaches here. The first is for a user to generate their own key and enrol it in their system firmware. We'll trust anything that's signed with a key that's present in the firmware. The second is to rebuild the shim loader with their own key installed and then pay $99 and sign that with Microsoft. That means that they'll be able to give copies to anyone else and let them install it without any fiddling. The third is to just disable secure boot entirely, at which point the machine should return to granting the same set of freedoms as it currently does.
Πολλοί από τους χρήστες μας θέλουν να χτίζουν τους δικούς τους πυρήνες. Κάποιοι ακόμα θέλουν να χτίζουν τις δικές τους διανομές. Η υπογραφή του bootloader και του πυρήνα αποτελεί εμόδιο σε αυτό. Θα παρέχουμε όλα τα εργαλεία που θα χρησιμοποιούμε για την υπογραφή των δυαδικών μας αρχείων, αλλά για προφανείς λόγους δεν μπορούμε να παραδώσουμε και το κλειδί μας. Εδώ υπάρχουν τρεις προσεγγίσεις. Η πρώτη είναι να παράξει ο χρήστης το δικό του κλειδί και να το εντάξει στο firmware του συστήματός του. Θα εμπιστευόμαστε οτιδήποτε υπογεγραμμένο με κάποιο κλειδί στο firmware. Η δεύτερη είναι να ξαναχτίσει ο χρήστης τον φορτωτή του δικού του binary και να πληρώσει 99$ για να το υπογράψει με το κλειδί της Microsoft. Αυτό σημαίνει πως θα μπορεί να το διανέμει σε αντίγραφα στον οποιονδήποτε και να το εγκαθιστά χωρίς κάποιο κόλπο. Η τρίτη είναι απλά να απενεργοποιήσεις εντελώς το secure boot, οπότε το μηχάνημα θα γυρίσει στην παροχή των ίδιων ελευθεριών που παρέχει και σήμερα. But I don't trust Microsoft
- Αλλά εγώ δεν εμπιστεύομαι τη Microsoft A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. Barring firmware backdoors, it's possible to configure secure boot such that your computer will only run software you trust. Freedom means being allowed to run the software you want to run, but it also means being able to choose the software you don't want to run.
Ένα σύστημα σε custom mode θα πρέπει να σας επιτρέπει να διαγράψετε όλα τα υπάρχοντα κλειδιά και να τα αντικαταστήσετε με τα δικά σας. Μετά από αυτό, είναι απλά θέμα να επανα-υπογράψετε τον bootloader της Fedora (όπως είπα, θα παρέχουμε τα εργαλεία και την τεκμηρίωση γι αυτό) και θα έχετε έναν υπολογιστή που θα εκκινεί τη Fedora αλλά θα αρνείται να εκκινήσει κώδικα της Microsoft. Μπορεί να είναι λίγο πιο περίπλοκο σε ένα desktop γιατί θα πρέπει να χειριστείτε τους υπογεγραμμένους οδηγούς της κάρτας γραφικών με την υπογραφή της Microsoft και της κάρτας δικτύου, αλλά και αυτό επιλύεται. Επεξεργάζομαι ένα εργαλείο που θα επιτρέπει να βάζετε σε λευκή λίστα τους εγκατεστημένους drivers. Αποτρέποντας τα backdoors του firmware, είναι δυνατόν να διαμορφώσετε το secure boot ώστε να εκτελείται μόνο λογισμικό που εμπιστεύεστε. Ελευθερία σημαίνει να μπορείς να τρέχεις το λογισμικό που θέλεις, αλλά και να μπορείς να επιλέγεις και το λογισμικό που δεν θέλεις να τρέχεις.You've sold out
- Πουληθήκατε We've been working on this for months. This isn't an attractive solution, but it is a workable one. We came to the conclusion that every other approach was unworkable. The cause of free software isn't furthered by making it difficult or impossible for unskilled users to run Linux, and while this approach does have its downsides it does also avoid us ending up where we were in the 90s. Users will retain the freedom to run modified software and we wouldn't have accepted any solution that made that impossible.
Δουλεύουμε σ' αυτό για μήνες. Δεν είναι ελκυστική λύση, αλλά είναι εφαρμόσιμη. Καταλήξαμε στο συμπέρασμα πως οποιαδήποτε άλλη λύση δεν θα δούλευε. Ο σκοπός του ελεύθερου λογισμικού δεν προωθείται κάνοντάς δύσκολο ή και αδύνατο σε χρήστες με λίγες ικανότητες το να τρέξουν Linux και ενώ αυτή η προσέγγιση έχει τα μειονεκτήματά της αποτρέπει επίσης το να βρεθούμε εκεί που βρισκόμασταν το '90. Οι χρήστες θα διατηρήσουν την ελευθερία να τρέχουν τροποποιημένο λογισμικό και δεν θα δεχόμασταν μια λύση που θα το καθιστούσε αυτό αδύνατο.But is this a compromise? Of course. There's already inequalities between Fedora and users - trademarks prevent the distribution of the Fedora artwork with modified distributions, and much of the Fedora infrastructure is licensed such that some people have more power than others. This adds to that inequality. It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be.
Είναι όμως αυτό συμβιβασμός; Φυσικά. Υπάρχουν ήδη ανισότητες μεταξύ Fedora και χρηστών - τα trademarks προλαμβάνουν τη διανομή του artwork της Fedora με τροποποιημένες διανομές και πολλή από την υποδομή της Fedora είναι αδειοδοτημένηη έτσι ώστε κάποιοι να έχουν περισσότερη δύναμη από άλλους. Αυτό προσθέτει στην ανισότητα. Δεν είναι το ιδανικό αποτέλεσμα για όλους και λυπάμαι ειλικρινά που δεν μπορέσαμε να βρούμε μια καλύτερη λύση. Αυτό δεν είναι τόσο κακό όσο φοβόμουν, αλλά ούτε τόσο καλό όσο ήλπιζα.What about ARM
- Τί θα γίνει με το ARMMicrosoft's certification requirements for ARM machines forbid vendors from offering the ability to disable secure boot or enrol user keys. While we could support secure boot in the same way as we plan to on x86, it would prevent users from running modified software unless they paid money for a signing key. We don't find that acceptable and so have no plans to support it.
Οι απαιτήσεις πιστοποίησης της Microsoft για μηαχνήματα ARM απαγορεύει στους κατασκευαστές τη δυνατότητα απενεργοποίησης του secure boot ή την ενσωμάτωση κλειδιών του χρήστη. Αν και θα μπορούσαμε να υποστηρίξουμε το secure boot κατά τον ίδιο τρόπο όπως σκοπεύουμε να κάνουμε στην πλατφόρμα Χ86, θα απέτρεπε τους χρήστες από το να τρέχουν τροποποιημένο λογισμικό εκτός αν πλήρωναν για ένα κλειδί υπογραφής. Το θεωρούμε απαράδεκτο και δεν σκοπεύουμε να το υποστηρίξουμε.Thankfully this shouldn't be anywhere near as much of a problem as it would be in the x86 world. Microsoft have far less influence over the ARM market, and the only machines affected by this will be the ones explicitly designed to support Windows. If you want to run Linux on ARM then there'll be no shortage of hardware available to you.
Ευτυχώς αυτό δεν θα πρέπει να είναι τόσο μεγάλο πρόβλημα όσο θα ήταν στον κόσμο του Χ86. Η Microsoft έχει πολύ λιγότερη επιρροή στην αγορά ARM και οι μόνες συσκευές που επηρεάζονται από αυτό θα είναι αυτές που θα σχεδιαστούν ειδικά για να υποστηρίζουν windows. Αν θελήσετε να τρέξετε Linux σε ARM δεν θα έχετε έλλειψη διαθέσιμου hardware. Is this all set in stone?
- Είναι τελικό όλο αυτό;No. We've spent some time thinking about all of this and are happy that we can implement it in the Fedora 18 timescale, but there's always the possibility that we've missed something or that a new idea will come up. If we can increase user freedom without making awful compromises somewhere else then we'll do it.
Όχι. Ξοδέψαμε κάμποσο χρόνο σκεπτόμενοι όλο αυτό και είμαστε ευχαριστημένοι που μπορούμε να το υλοποιήσουμε στο χρονοδιάγραμμα της Fedora 18, αλλά υπάρχει πάντα η πιθανότητα να προκύψει μια νέα ιδέα. Αν μπορούμε να αυξήσουμε την ελευθερία του χρήστη αποφεύγοντας κάποιον απαίσιο συμβιβασμό κάπου αλλού τότε θα το κάνουμε.[1] In fact, chances are that everything will carry the Microsoft key. Secure boot requires that UEFI drivers also be signed. The signing format only permits a single signature per binary. For compatibility, approximately all add-on hardware shipped will be signed with Microsoft's key, and that means that all system vendors have to recognise Microsoft's key in order to permit that hardware to run on their systems.
[1] Στην πράξη, οι πιθανότητες είναι πως όλα θα έχουν το κλειδί της Microsoft. Το Secure boot απαιτεί οι UEFI drivers να είναι επίσης υπογεγραμμένοι. Η μορφή της υπογραφής επιτρέπει μόνο μια υπογραφή ανά binary. Γιοα λόγους συμβατότητας, όλο το πρόσθετο hardware θα αποστέλλεται υπογεγραμμένο με το κλειδί της Microsoft και αυτό σημαίνει πως όλοι οι κατασκευαστές θα πρέπει να αναγνωρίζουν το κλειδί της Microsoft για να επιτρέπουν σε αυτό το hardware να τρέχει στα συστήματά τους. [2] Current source is
here. It relies on a port of the UEFI crypto library and OpenSSL that I have building with some handholding, and which I'll upload as soon as possible.
[2] Η τρέχουσα πηγή είναι εδώ. Βασίζεται σε ένα port της βιβλιοθήκης κρυπτογράφησης UEFI και σε OpenSSL το οποίο αναπτύσσω και θα ανέβει όσο το συντομότερο. 
