Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
553 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2  3
Page Suivante
Auteur Sujet :

UEFI Secure Boot

n°1341196
odelpasso
Posté le 10-07-2013 à 19:54:25  profilanswer
 

Reprise du message précédent :

MysterieuseX a écrit :


Je suis certaine que t'as un firmware UEFI et que le secure boot est pas loin, donne les refs :)


 
Euh... Comment je peux te donner cela ?
 
Je n'en suis pas si sur que j'ai de l'UEFI+SB car :
1- le BIOS en lui-même, c'est du old-BIOS donc navigation aux flèches directionnelles. Comparé au BIOS+UEFI ou l'on peut naviguer à la souris
2- Aucune option dans le BIOS du PC Portable permettant d'activer ou de désactiver l'UEFI et/ou le SB
3- Test fait après l'installation d'une Debian Sid (l'installeur Wheezy installe de lui-même grub-efi comme un grand) :

Citation :

berillions@debian64:~/.wine/drive_c/Program Files/Origin$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session non-EFI


 
4- Même test sous Windows 7 installé le jour même de la reception du PC, la seule chose que j'ai modifié dans le BIOS, c'était de booter sur le DVD. Or, je ne pouvais booter que sur le mode "DVD classique". Aucune trace du mode "DVD UEFI"

Citation :

Microsoft Windows [version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous droits réservés.
 
C:\Windows\system32>bcdedit
 
Chargeur de démarrage Windows
-----------------------------
identificateur          {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  fr-FR
inherit                 {bootloadersettings}
recoverysequence        {a4977394-d75a-11e2-846a-df1c2733eb39}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {a4977392-d75a-11e2-846a-df1c2733eb39}
nx                      OptIn


 
Un OS Windows installé en UEFI devrait donner en "path" ceci : "\Windows\system32\winload.efi"

mood
Publicité
Posté le 10-07-2013 à 19:54:25  profilanswer
 

n°1341593
Mysterieus​eX
Chieuse
Posté le 17-07-2013 à 18:52:07  profilanswer
 

odelpasso a écrit :


 
Euh... Comment je peux te donner cela ?
 
Je n'en suis pas si sur que j'ai de l'UEFI+SB car :
1- le BIOS en lui-même, c'est du old-BIOS donc navigation aux flèches directionnelles. Comparé au BIOS+UEFI ou l'on peut naviguer à la souris
2- Aucune option dans le BIOS du PC Portable permettant d'activer ou de désactiver l'UEFI et/ou le SB
3- Test fait après l'installation d'une Debian Sid (l'installeur Wheezy installe de lui-même grub-efi comme un grand) :

Citation :

berillions@debian64:~/.wine/drive_c/Program Files/Origin$ [ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"
Session non-EFI


 
4- Même test sous Windows 7 installé le jour même de la reception du PC, la seule chose que j'ai modifié dans le BIOS, c'était de booter sur le DVD. Or, je ne pouvais booter que sur le mode "DVD classique". Aucune trace du mode "DVD UEFI"

Citation :

Microsoft Windows [version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous droits réservés.
 
C:\Windows\system32>bcdedit
 
Chargeur de démarrage Windows
-----------------------------
identificateur          {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  fr-FR
inherit                 {bootloadersettings}
recoverysequence        {a4977394-d75a-11e2-846a-df1c2733eb39}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {a4977392-d75a-11e2-846a-df1c2733eb39}
nx                      OptIn


 
Un OS Windows installé en UEFI devrait donner en "path" ceci : "\Windows\system32\winload.efi"


 
On s'en fou de savoir comment boot ton OS, en fait ton OS boot en mode legacy parce que ton firmware est en mode de compatibilité. Tu confond UEFI, BIOS, Secure Boot et tout le reste. Je te demandais le modèle de ton portable. (mais vue que t'as un G70) c'est un firmware AMI Aptio qui est un UEFI.

n°1354222
guimo33
Random guy
Posté le 11-03-2014 à 14:38:01  profilanswer
 

Re,
 
Ca y est, j'ai acheté une nouvelle machine, et au lieu de profiter bien tranquillement de ma distro préférée, je suis en train de me dépetrer avec l'UEFI et son fonctionnement usinagazeux. :fou:  
 
J'explique : hier j'ai fait un clear CMOS car le Fastboot faisait redémarrer mon ordi en boucle. Normal, fastboot est incompatible avec Debian, j'aurais du me renseigner,  [:dje69r:3]  
 
 
Normalement, un clear CMOS est une opération de routine sans grand danger, mise à part qu'il faut refaire deux trois réglages dans le bios (ordre de démarrage etc.)
Mais avec l'UEFI, grave erreur!
 
L'UEFI stocke en NVRAM le chemin de démarrage dans la partition de boot! Comme j'utilise grub (et non windows), l'application s'appelle grubx64.efi à la place du nom habituel pour windows.
Et bien sur, aucun moyen de modifier ce chemin dans mon interface de setup.
 
MAIS QUEL PETIT CERVEAU MALADE A PU INVENTER CA? On te vente UEFI pour son interface clavier souris, alors qu'il y a même pas un outil intégré pour choisir l'image . efi de démarrage!!! [:prozac]  [:stockholm]  [:jesus_consteration]  [:black_jack]  [:benn25]  [:michelnet1]  [:lehman brothers]  
 
Il me reste 4 solutions :  
- repasser en mode de compatibilité BIOS, mais je ne veux pas, car il faut bien me préparer au futur
- utiliser un CD de recue et l'utilitaire efibootmgr de Linux, pour corriger le chemin de boot en nvram (solution élégante)
- idem, mais avec le shell uefi (solution élégante aussi)
- réinstaller grub avec le paquet ou grub-install.
 
Si vous avez d'autres solutions, je suis preneur. Carte mère ASUS Vanguard B85.

Message cité 1 fois
Message édité par guimo33 le 11-03-2014 à 14:55:03
n°1354237
Mysterieus​eX
Chieuse
Posté le 12-03-2014 à 00:32:11  profilanswer
 

guimo33 a écrit :

Re,
 
Ca y est, j'ai acheté une nouvelle machine, et au lieu de profiter bien tranquillement de ma distro préférée, je suis en train de me dépetrer avec l'UEFI et son fonctionnement usinagazeux. :fou:  
 
J'explique : hier j'ai fait un clear CMOS car le Fastboot faisait redémarrer mon ordi en boucle. Normal, fastboot est incompatible avec Debian, j'aurais du me renseigner,  [:dje69r:3]  
 
 
Normalement, un clear CMOS est une opération de routine sans grand danger, mise à part qu'il faut refaire deux trois réglages dans le bios (ordre de démarrage etc.)
Mais avec l'UEFI, grave erreur!
 
L'UEFI stocke en NVRAM le chemin de démarrage dans la partition de boot! Comme j'utilise grub (et non windows), l'application s'appelle grubx64.efi à la place du nom habituel pour windows.
Et bien sur, aucun moyen de modifier ce chemin dans mon interface de setup.
 
MAIS QUEL PETIT CERVEAU MALADE A PU INVENTER CA? On te vente UEFI pour son interface clavier souris, alors qu'il y a même pas un outil intégré pour choisir l'image . efi de démarrage!!! [:prozac]  [:stockholm]  [:jesus_consteration]  [:black_jack]  [:benn25]  [:michelnet1]  [:lehman brothers]  
 
Il me reste 4 solutions :  
- repasser en mode de compatibilité BIOS, mais je ne veux pas, car il faut bien me préparer au futur
- utiliser un CD de recue et l'utilitaire efibootmgr de Linux, pour corriger le chemin de boot en nvram (solution élégante)
- idem, mais avec le shell uefi (solution élégante aussi)
- réinstaller grub avec le paquet ou grub-install.
 
Si vous avez d'autres solutions, je suis preneur. Carte mère ASUS Vanguard B85.


 
Explique moi ton problème en détails, parce que là je sais même pas se que tu veux faire.

n°1354238
Magicpanda
Pushing the envelope
Posté le 12-03-2014 à 07:03:09  profilanswer
 

2 pages de wiki utiles
https://wiki.archlinux.org/index.ph [...] _Interface
https://wiki.archlinux.org/index.php/Boot_Loaders


---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
n°1354242
Mysterieus​eX
Chieuse
Posté le 12-03-2014 à 08:26:46  profilanswer
 


 
Entre nous, elles amènent a rien ces pages de wiki, rien d'utilisable en l'état.
Déjà, elles disent pas qu'il faut une ESP sur un des disques dur, d'ailleurs, c'est mis nul part. Ensuite, ça dit pas que pour que ça fonctionne, il faut les .efi stockés suivant une structure précise dans l'ESP, ensuite, ça dit pas comment faire pour installer un système proprement peut importe l'OS installé par la suite, ni comment manipuler la NVRAM sans bricker ton installation toutes les 2 secondes.
 
D'ailleurs et ironiquement, ces pages WIKI recommandent d'utiliser GRUB, alors que GRUB est fort pour bricker les NVRAM si tu t'y connais pas. Le "mieux" reste rEFInd + UEFI stub et chemin en dur dans le kernel, kernel stocké dans l'ESP.


Message édité par MysterieuseX le 12-03-2014 à 08:28:50
n°1354256
guimo33
Random guy
Posté le 12-03-2014 à 09:56:17  profilanswer
 

Alors le Kernel stocké dans l'ESP, je dis 1000x oui! Effectivement, grub est pour moi un "point of failure" dans le cas de EFI (en plus d'être inutile). Mais bon, l'inertie de Linux, fera qu'on se le paluchera encore une bonne paire d'année.
 
Pour revenir à mon problème :  Suite à un reset CMOS, la nvram ne pointait plus vers l'image de démarrage "grubx64.efi" (qui n'est pas un nom "standard" d'image efi).
 
J'ai résolu le problème de la manière suivante:
- reboot sur une clé usb uefi contenant la netinstall debian
- lorsque grub se lance, j'appuie sur la touche "c"
- à l'aide de la commande "ls" de grub, je cherche la partition et le chemin qui contiennent le ficher de configuration de grub sur le disque du de démarrage (grub.cfg, généralement dans le dossier /boot/grub )
- J'invoque ce fichier avec la commande configfile
- grub continue de démarrer via ce fichier, du coup le menu normal s'affiche, et le pc boote correctement
- je me connecte en root et j'utilise la commande "grub-install" pour remettre grub d'équerre.
 
Comme j'ai le gout du risque et de la compréhension, j'ai replanté mon PC de la même manière qu'avant : fastboot activé puis clear cmos via le jumper. Etonnament, la nvram n'a pas été effacée alors que tout le reste du bios a été remis à zero. Idem après le flashage du bios EFI en dernière version...
Du coup, je suis plus rassuré, je pense que le reset de la nvram était un bug. Visiblement, il n'est pas stocké en cmos.
Au passage question con : quel est le meilleur shell efi à utiliser en ce moment?

Message cité 1 fois
Message édité par guimo33 le 12-03-2014 à 10:07:24
n°1354257
Mysterieus​eX
Chieuse
Posté le 12-03-2014 à 10:21:00  profilanswer
 

guimo33 a écrit :

Alors le Kernel stocké dans l'ESP, je dis 1000x oui! Effectivement, grub est pour moi un "point of failure" dans le cas de EFI (en plus d'être inutile). Mais bon, l'inertie de Linux, fera qu'on se le paluchera encore une bonne paire d'année.
 
Pour revenir à mon problème :  Suite à un reset CMOS, la nvram ne pointait plus vers l'image de démarrage "grubx64.efi" (qui n'est pas un nom "standard" d'image efi).
 
J'ai résolu le problème de la manière suivante:
- reboot sur une clé usb uefi contenant la netinstall debian
- lorsque grub se lance, j'appuie sur la touche "c"
- à l'aide de la commande "ls" de grub, je cherche la partition et le chemin qui contiennent le ficher de configuration de grub sur le disque du de démarrage (grub.cfg, généralement dans le dossier /boot/grub )
- J'invoque ce fichier avec la commande configfile
- grub continue de démarrer via ce fichier, du coup le menu normal s'affiche, et le pc boote correctement
- je me connecte en root et j'utilise la commande "grub-install" pour remettre grub d'équette.
 
Comme j'ai le gout du risque et de la compréhension, j'ai replanté mon PC de la même manière qu'avant : fastboot activé puis clear cmos via le jumper. Etonnament, la nvram n'a pas été effacée alors que tout le reste du bios a été remis à zero. Idem après le flashage du bios EFI en dernière version...
Du coup, je suis plus rassuré, je pense que le reset de la nvram était un bug. Visiblement, il n'est pas stocké en cmos.
Au passage question con : quel est le meilleur shell efi à utiliser en ce moment?


 
Fait plus "simple" et vraiment brickless :
Par défaut la NVRAM asus ira pointer vers bootmgr.efi (qui est le bootmanager de windows), c'est parce qu'Asus est con et donc Asus, en cas de gros pépins cherche du windows, ils ne respectent pas le "standard". Cela dit, on peut faire "sans" voir même carrément plus propre.
Ton ESP doit avoir une structure :
la racine de ton ESP doit contenir un dossier EFI, ce dossier EFI doit contenir un dossier par "bootloader" et/ou OS ainsi moi j'ai :
ESP
-shell.efi
-EFI
--windows
---bootmgr.efi (et d'autres trucs)
--ubuntu
---Mok.efi (et d'autres trucs relatif au grub spécifique pour ubuntu)
--rEFInd
---(des trucs pour rEFInd)
--Gentoo
---kernel.efi
--Tools
---memtest.efi
---tianocore.efi
---différents shells
 
Donc la structure doit de préférence toujours être celle ci a savoir ton shell de base a la racine et tes bootloader.
Dans mon cas, je laisse refind s'occuper des paramètres de boot puisqu'il est très très bon pour l'autodetection (en plus de pouvoir accéder aux outils)
 
Pour l'astuce "brickless" sur asus, ca consiste a modifier l'entrée taggée bootmgr.efi et la faire pointer (en gardant son tag) vers le gestionnaire de ton choix (comme ça tu gruge le firmware)
 
C'est pas le nom de l'image qui n'est pas standard mais les fabricants de mobal qui ne respectent pas le standard intel (opensource je le rappel) pour avoir la certification "windows ready".
Dans mon cas, je pointe mon bootmgr.efi vers refind.
 
Sous visualBCDeditor ca donne ça (note que gentoo étant stubbé chez moi, il n'apparait pas, je boot directement le kernel sur la partoche en ext2 via detection rEFInd):
http://hfr-rehost.dev.syn.fr/preview/self/3e4a5b2328eecbb8b6e44bc8db188576faf7c046.png
 
Edit : tianocore/EDK2 pour le shell
http://sourceforge.net/apps/mediaw [...] UEFI_Shell
(je te conseille d'apprendre a le compiler pour par exemple avoir le clavier en azerty au lieu du qwerty du package binaire)


Message édité par MysterieuseX le 12-03-2014 à 10:27:16
n°1354258
guimo33
Random guy
Posté le 12-03-2014 à 10:35:25  profilanswer
 

Merci!
Par contre, j'ai pas compris ce que que tu appelles "pointer" : sur ma machine, point de Windows! Au pire, je pourrais faire une copie de mon fichier de grub vers windows/bootmgr.efi, mais je ne trouve pas ca nickel (même si ca risque de fonctionner)

n°1354259
Mysterieus​eX
Chieuse
Posté le 12-03-2014 à 10:42:25  profilanswer
 

guimo33 a écrit :

Merci!
Par contre, j'ai pas compris ce que que tu appelles "pointer" : sur ma machine, point de Windows! Au pire, je pourrais faire une copie de mon fichier de grub vers windows/bootmgr.efi, mais je ne trouve pas ca nickel (même si ca risque de fonctionner)


Pointer : modifier les infos BC dans la NVRAM, faut comprendre la structure.
Tiens, si tu veux te marrer :

Citation :

Default Boot Behavior
Firmware vendors must ensure that the following conditions exist:
The BIOS ignores boot entries that do not have the 80x86 Platform ID, which is defined as “0x00” in hexadecimal. Failure to ignore other boot entries results in the display of a confusing boot menu to the end user.
The BIOS boots based on the BIOS entry without prompt.
The UEFI boot manager ignores boot entries that do not have the “0xEF” Platform ID.
The UEFI boot manager boots based on the EFI entry without prompt.
 
To support the ability to boot from DVD media, the Windows installation DVD contains many El Torito boot entries that enable boot from either BIOS or UEFI. The default El Torito boot entry is for BIOS.
Windows Server 2008 R2 and Windows 7 include support for the “Non-removable Media Boot Behavior” section that was added to the UEFI 2.3 specification. These versions of Windows copy the Windows boot application from \efi\microsoft \boot\bootmgfw.efi to \efi\boot\boot{arch}.efi on the EFI system partition during initial installation and when updates are required for bootmgfw.efi. This copy enables a default boot option for Windows if a nonvolatile RAM (NVRAM) boot entry is not available, such as when a hard disk is moved from one platform to another.


 
Le mieux, c'est d'installer rEFInd et de le laisser en "hard" a deux endroits, nommé de deux manières différentes : ESP/EFI/rEFInd/ et ESP/EFI/boot/ (ou il sera renomé en bootx64.efi), tu modifiera son tag pour qu'il soit équivalent a {bootmgr.efi} comme ça ton firmware asus te fera plus jamais chier.
 
Edit : et j'espère que maintenant tu comprend mieux quand je dit que le problème n'est pas microsoft vis a vis des utilisateurs, mais bel et bien les fabricants OEM qui veulent absolument leurs "certified for windows" ?


Message édité par MysterieuseX le 12-03-2014 à 10:44:01
mood
Publicité
Posté le 12-03-2014 à 10:42:25  profilanswer
 

n°1354260
guimo33
Random guy
Posté le 12-03-2014 à 10:50:46  profilanswer
 

Oui, je comprend et je suis moins enervé. Reste que je trouve que tout cela est bien "compliqué" juste pour booter. Je ne peux pas reprocher aux fabriquants de n'implémenter que le stricte nécessaire pour que ça fonctionne, car dans ce cas je trouve les specs complexes. M'enfin, je ne referai pas le monde.
 
En fait, je pense que c'est ce que fait grub-install, non? Modifier la nvram pour booter vers l'image du grub?

Message cité 1 fois
Message édité par guimo33 le 12-03-2014 à 11:00:19
n°1354266
Mysterieus​eX
Chieuse
Posté le 12-03-2014 à 11:11:57  profilanswer
 

guimo33 a écrit :

Oui, je comprend et je suis moins enervé. Reste que je trouve que tout cela est bien "compliqué" juste pour booter. Je ne peux pas reprocher aux fabriquants de n'implémenter que le stricte nécessaire pour que ça fonctionne, car dans ce cas je trouve les specs complexes. M'enfin, je ne referai pas le monde.
 
En fait, je pense que c'est ce que fait grub-install, non? Modifier la nvram pour booter vers l'image du grub?


Ouip, mais grub est crade et doit le refaire a chaque mise a jour kernel ou presque. Grub est con, c'est pas sa faute.
 
Pour l'UEFI le plus complexe a assimiler c'est :
Fast boot = désactivation du CSM = matériel compatible uniquement (c'est le seul point limitant en fait, donc dans ton cas se qui fesait reboot en boucle ça doit être la carte graphique pas compatible GOP) = on désactive dans le doute (y'a rien pour le grand publique qui permette de dire si la totalité de son matériel est "ok" ).
Secure Boot = compliqué a mettre en oeuvre, faut signer ses kernels avec une private key générée via un utilitaire sur la config, puis intégrer la key avec mokmanager. Ensuite tu peu booter par ton shim.efi (avec la séquence de boot qui devient shim.efi > grub signé (ou refind signé) > kernel signé) = on désactive si on maitrise pas (et jusqu'a présent y'a rien de brainless de mis en place pour le grand publique donc, techno intéressante mais chiante)
 
A partir de là, faut s'assurer de plusieurs points :
-on commence par partitionner son disque en GPT, avec ESP en fat32 en partition 1 (ça évite aux firmwares un peu pourris de s’emmêler)
-on installe refind et tout ses fichiers dans (partitionESP)/EFI/boot/
-on renome notre refind en "bootx64.efi"
-on laisse grub s'installer, il va aller detecter tout seul ou se mettre ((partitionESP)/EFI/debian ou autre) et surtout on lui dit de ne pas modifier les entrées dans la NVRAM
-Quoi qu'il arrive on touche plus a la NVRAM, de toute façon, refind est plus intéligent que n'importe quel bootloader/bootmanager existant.

n°1354269
guimo33
Random guy
Posté le 12-03-2014 à 11:30:16  profilanswer
 

ok, merci!
 
En fait, c'est pas le fasboot à proprement parler qui posait problème. C'est une autre option "démarrage rapide hardware" qui vient en complément du fastboot et qui est désactivée par défaut. Cette fonction contourne complètement le POST, tellement que mon PC reboot en boucle, avant même que je puisse faire F2!

n°1354379
Mysterieus​eX
Chieuse
Posté le 14-03-2014 à 20:04:54  profilanswer
 

Devenir votre propre autorité de certification et vous passer des clés microsoft mais malgré tout utiliser secure boot ? Oui c'est possible. Compliqué actuellement mais possible.
 
Un tuto en anglais (source : http://www.rodsbooks.com/efi-bootl [...] boot.html)
TLDR :  
-Récupérer GNU-EFI
-Compiler efitools (qui ira générer vos certificats perso et le lockdown.efi)
-Compiler sbsigntools
-signer vos binaires de bootload/bootchain (pour signer une distro linux par exemple il faut signer le grub, grub une fois signé permettant de passer outre ... Vive le POF :o, ou bien signer votre kernel "stubbé" )  
-préparer vos fichiers a installer via le shell
-installer vos clés et passer votre firmware en mode lockdown
 
Step by step en anglais :  

Citation :

Replacing Your Firmware's Keys
 
It's possible to replace Microsoft's keys with your own. This can be a useful approach if you want the benefits of Secure Boot but don't want to trust Microsoft or any of the others who will be signing binaries with the Microsoft keys. There are three main steps to this process: generating your own keys, signing your binaries, and installing your keys in your firmware. I describe each of these steps in turn. Be aware that, at least as of late 2012, the procedures required to add your own keys are fairly advanced. For instance, I describe how to obtain the necessary Linux software via git and to compile it locally. If you're not comfortable with such procedures, you may have to abandon this approach.
 
Generating Your Own Keys
 
The first step to using your own Secure Boot keys is to generate these keys. To do so, you must first install two programs, neither of which is yet widely available in binary form. The first of these programs is efitools and the second is sbsigntool (the same program used to sign MOKs). Both programs rely on the GNU-EFI library. The procedure for installing all of these packages is as follows:
 
Go to the GNU-EFI Web site and download version 3.0r of the package (gnu-efi_3.0r.orig.tar.gz). Officially, version 3.0q or later is required; however, I've found that version 3.0s produces binaries that don't work. Perhaps this problem will be fixed in future versions of GNU-EFI or of the programs that build against it.
Unpack gnu-efi_3.0r.orig.tar.gz, cd into the resulting directory, type make to build the package, and then type make install as root to install it.
Change to your home directory or some other convenient location, such as /usr/src, and type git clone git://kernel.ubuntu.com/jk/sbsigntool. This step will succeed only if the git program is installed, so you may need to install it. Alternatively, you can download and install a binary package from the OpenSUSE Build Service and skip ahead to step #10.
Change into the sbsigntool directory that results and type ./autogen.sh. This step retrieves additional source code into the sbsigntool directory tree. (If you get error messages about various programs, including automake, not being found, you must install the automake package and repeat this step.)
Edit the configure script and change every instance of the string /usr/include/efi to /usr/local/include/efi. (You should omit this step if you installed GNU-EFI so that its include files reside in /usr/include/efi.)
Type ./configure to configure the package. If this produces error messages about missing development packages, you must install them and repeat this step until it succeeds.
Type make to build the package.
As root, type make install to install the sbsigntool programs.
Back out of the sbsigntool directory (to your home directory or /usr/src, for example).
Type git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git. This action produces a directory called efitools containing additional source code.
Change into the efitools directory.
Open the Make.rules file in a text editor and replace every instance of /usr/include/efi with /usr/local/include/efi. (They're all on the INCDIR line early in the file.) While still editing this file, change every instance of /usr/lib64 to /usr/local/lib. Note both the inclusion of the local subdirectory and the change from lib64 to lib. (This change won't be necessary, or a variant of it may be needed, if you installed GNU-EFI from a binary package.)
Type make. The result should be a number of files and programs, most notably including LockDown.efi, which installs keys that were generated during the build process.
Back out of the efitools directory.
Copy the entire efitools directory to a medium that you can read on your target computer. This could be the EFI System Partition (ESP) on the computer you used to build the files or a FAT partition on a USB flash drive, for instance.
At this point, you have Secure Boot keys in files within the efitools directory, and the LockDown.efi program will install them once you run it from an EFI shell program under the right circumstances. Of course, there's no point to locking down the firmware unless you have a signed boot loader, so that's the next step....
 
Signing Your Binaries
 
You'll presumably want to sign binaries such as grub.efi or a Linux kernel with an EFI stub loader. Furthermore, if you're planning to dual-boot with Windows or some other OS, you'll probably have to sign its boot loader, too. This is true even if it's already been signed with another key—the procedure described on this page replaces your firmware's existing keys, so existing signatures will no longer work, and you must therefore replace the signatures on existing binaries.
 
In any event, the procedure to sign an EFI binary is fairly straightforward, once you've installed the sbtools package and created keys by preparing the efitools package:

$ sbsign --key ~/efitools/DB.key --cert ~/efitools/DB.crt \
         --output vmlinuz-signed.efi vmlinuz.efi
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table?


This example signs the vmlinuz.efi binary, located in the current directory, writing the signed binary to vmlinuz-signed.efi. Of course, you must change the names of the binaries to suit your needs, as well as adjust the path to the keys (DB.key and DB.crt).
 
This example shows two warnings. I don't claim to fully understand them, but they don't seem to do any harm—at least, the Linux kernel binaries I've signed that have produced these warnings have worked fine. Another warning I've seen on binaries produced with GNU-EFI also seems harmless:

warning: data remaining[1231832 vs 1357089]: gaps between PE/COFF sections?


On the other hand, the ChangeLog file for GNU-EFI indicates that binaries created with GNU-EFI versions earlier than 3.0q may not boot in a Secure Boot environment when signed, and signing such binaries produces another warning:

warning: gap in section table:
    .text   : 0x00000400 - 0x00019c00,
    .reloc  : 0x00019c91 - 0x0001a091,
warning: gap in section table:
    .reloc  : 0x00019c91 - 0x0001a091,
    .data   : 0x0001a000 - 0x00035000,
gaps in the section table may result in different checksums


If you see a warning like this, you may need to rebuild your binary using a more recent version of GNU-EFI.
 
If you're using rEFIt, rEFInd, or gummiboot, you must sign not just those boot manager binaries, but also the boot loaders that they launch, such as Linux kernels or ELILO binaries. If you fail to do this, you'll be unable to launch the boot loaders that the boot managers are intended to launch. Stock versions of ELILO and GRUB don't check Secure Boot status or use EFI system calls to load kernels, so even signed versions of these programs will launch any kernel you feed them. This defeats the purpose of Secure Boot, though, at least when launching Linux. At least some future versions of GRUB will communicate with shim for authenticating Linux kernels and so may refuse to launch a Linux kernel that's not been signed.
 
Once you've signed your binaries, you should install them to your ESP as you would an unsigned EFI binary. Signed binaries should work fine even on systems on which you've disabled Secure Boot.
 
As a side note, the pesign utility, available from git://github.com/vathpela/pesign.git, is an alternative to sbtools; however, because efitools is coded to use sbtools, I've barely looked at pesign. You might want to check it out if you have problems with sbtools, though.
 
Installing Your Own Keys
 
With your keys ready and your binaries signed, you can now configure your computer to use them. Unfortunately, this process is likely to vary greatly from one EFI implementation to another. The following is based on my experiences with an ASUS P8H77-I motherboard, so if you're using a different EFI implementation, you may need to look for options that are similar but not identical to those described here, or even deviate very substantially from the following instructions. With that caveat out of the way, here's how to install Secure Boot keys on at least some computers:
 
Prepare an EFI-bootable medium that contains an EFI shell. You could install the EFI shell as EFI/BOOT/bootx64.efi or set it up so that it can be launched from the EFI's own boot manager or from rEFInd or gummiboot. Test to be sure you can enter this shell. (If Secure Boot is already enabled, you'll need to disable it first.)
Enter the computer's firmware utility by pressing Del during the initial stages of the boot process (before any boot loader appears). Some computers use other keys for this purpose; examine your early boot-time messages or read your computer's manual to learn what to use.
If you're configured to boot in EZ Mode, press F7 to enter Advanced Mode.
Click the Boot tab.
Click Security Boot Parameters near the bottom-left of the screen. (It's conceivable you'll need to scroll down to see this on some systems.)
For OS Type, select Windows 8 UEFI. (Yes, even if you're not going to boot Windows.)
For Secure Boot Mode, select Custom. The screen should look something like this:
http://www.rodsbooks.com/efi-bootloaders/secureboot1.jpg
Click Key Management to get to the page in which you can manage keys, as shown here:
http://www.rodsbooks.com/efi-bootloaders/secureboot2.jpg
Set Default Key Provisioning to Disable.
Click Clear Secure Boot Keys to remove any old keys.
If you placed the efitools directory on a USB flash disk, insert it into the computer.
Press F10 to save your changes and reboot the computer.
If necessary, as the computer starts up, press F8 to enter the firmware's boot manager to select the medium you prepared to boot the EFI shell. (F8 is the key that ASUS uses in the P8H77-I to load the boot manager; this key may be different on other computers.)
Launch your EFI shell.
Change to the filesystem holding efitools and enter that directory. For instance, you might type fs4: followed by cd efitools.
Type LockDown.efi to enter your keys into the firmware and enable Secure Boot mode. If you receive a message to the effect that the computer is not in Setup mode, then you should review the last few steps; or if you're using firmware other than ASUS', you may need to experiment to learn how to kick your system into Setup mode. Alternatively, you could try loading your various keys manually using the various Set ... from File options in the user interface.
At this point, your computer should be set up for Secure Boot. (If you haven't already installed your signed EFI binaries, though, you must do so now.) You should be able to reboot and use the signed binaries; but unsigned binaries, or those signed by anybody but you, should not run.


 
Avec ceci on peu de manière relativement simple a condition de suivre scrupuleusement les indications (testé et approuvé par mes soins) :
Signer a peu prêt tout et n'importe quoi et avoir Secure Boot d'activé
Signer Windows XP/Vista/7, resigner Windows 8/8.1 et faire qu'il ne couine plus du coup.
Signer linux, freebsd, et 3/4 des OSA x86 et x86_64
Signer Mac OS
 
Avec un peu plus de difficultés on peu signer pour de l'ARM et remplacer les key secure boot microsoft ARM et donc vous comprendrez qu'on puisse avoir une tablette windows RT ET un autre OS.
 
En fait Windows ne demande qu'une chose : avoir secure boot d'activé pour être dans la position "idéale", pas d'avoir des clés PKK microsoft.
 
Concrètement si on peu signer ses propres binaires EFI, Secure Boot protège de quoi ?
Secure Boot protège d'une chose bien particulière : le hack kernel et l'installation d'un programme remplaçant celui-ci a distance et a condition que vos certificats et clés de signature ne soient pas a disposition de tout le monde :
-Si quelqu'un a accès a votre machine de manière physique, il peut désactiver secure boot dans le bios, remettre a 0 les clés et unlock le système
-Si quelqu'un a accès a vos clés de signature et vos certificats, il peut signer des binaires et les injecter quand même

Message cité 1 fois
Message édité par MysterieuseX le 14-03-2014 à 20:17:29
n°1354589
Ralph-
★ You'll hate me. ★
Posté le 18-03-2014 à 16:25:02  profilanswer
 

Joli post !

n°1354590
guimo33
Random guy
Posté le 18-03-2014 à 16:26:21  profilanswer
 

+1

n°1357329
T3K
Berserk Overkill Certified
Posté le 27-04-2014 à 15:26:46  profilanswer
 

MysterieuseX a écrit :

Devenir votre propre autorité de certification et vous passer des clés microsoft mais malgré tout utiliser secure boot ? Oui c'est possible. Compliqué actuellement mais possible.
[...]
Concrètement si on peu signer ses propres binaires EFI, Secure Boot protège de quoi ?
Secure Boot protège d'une chose bien particulière : le hack kernel et l'installation d'un programme remplaçant celui-ci a distance et a condition que vos certificats et clés de signature ne soient pas a disposition de tout le monde :
-Si quelqu'un a accès a votre machine de manière physique, il peut désactiver secure boot dans le bios, remettre a 0 les clés et unlock le système
-Si quelqu'un a accès a vos clés de signature et vos certificats, il peut signer des binaires et les injecter quand même


 
gros drapal
 :love:  
Pour le coup, pour moi c'est the best post ever on HFR, merci !!
LA réponse concrête à une question qui restait abstraite à bien trop de monde sur le fofo
C'est clair, c'est précis, c'est nickel quoi, je pourrais vraiment tester tout ça à fond quand j'aurais du temps libre :jap:


Message édité par T3K le 27-04-2014 à 15:35:00
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
grub rescue lors du boot[GRUB] Changer l'ordre de boot
comment installer linux sur netbook sans cd live et en dual boot[resolu] GRUB... et puis rien... /boot sur clef usb, / sur hdd
Triple boot et système de fichierDual boot Seven / Ubuntu, ordre création de partition
Boot kern 2.6.36 debian 5 hyper-vUEFI vous avez déjà été em...dé ?
Probleme de dual boot windows 7 et linux[RESOLU] Windows XP pas au boot apres installation d'Ubuntu
Plus de sujets relatifs à : UEFI Secure Boot



Copyright © 1997-2016 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR