Xorg "générique" pour carte nvidia plus supportée

Support Debian
#12

Bonsoir,

J’ai résolu mon problème et j’expose la solution parce qu’elle pourrait intéresser d’autres personnes.

En examinant le journal d’Xorg qui me fournissait une résolution dégradée, j’ai constaté la présence de la ligne :

(II) VESA(0): Not using built-in mode "1440x900" (hsync out of range)

J’en ai conclu que la résolution était connue mais que le « moniteur » n’était pas capable de l’afficher car sa plage de fréquences horizontales (31,50 - 48 kHz) est insuffisante.

cvt m’a donné la fréquence nécessaire : 53,93 kHz pour 1440x900 en 60 Hz vertical.

J’ai donc concocté un petit xorg.conf sur mesure

Section "Screen"
        Identifier "Screen0"
        Monitor "Monitor0"
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 30-60 
#       Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync

EndSection

qui augmente la plage de synchronisation horizontale.

Bingo.

Cordialement.

#13

C’est effectivement effrayant.

Mais ça, c’est seulement si tu utilises un démarrage de ta machine en mode EFI secure boot*** et si tu utilises l’EFI secure il n’y aura pas que pour le pilote de ta carte graphique qu’il te faudra une signature.

Par contre, en mode legacy, tu n’auras besoin d’aucune signature.

La sécurité des systèmes Linux est reconnue depuis bien longtemps et n’a absolument pas besoin (très doux euphémisme) de l’EFI

*** EFI secure en deux lignes :
Tout système d’exploitation autre que Windows sera considéré comme un système malveillant.
Il devra demander (acheter) une autorisation (signature) pour pouvoir fonctionner sur un PC

Les spécifications de lUEFI (2540 pages) :

#14

Bonjour,

Voilà une nuance dont je n’étais pas conscient.

Merci de m’avoir éclairé sur ce point.

Cordialement.

#15

Très souvent, si les utilisateurs choisissent de garder leur machine avec un démarrage en mode EFI
c’est parce que windows était déjà installé sur leur machine en mode EFI
Donc, s’ils veulent garder leur système Windows installé et fonctionnel, il est plus simple pour eux d’installer les autres systèmes d’exploitation en mode EFI, ou alors il leur faut trouver le moyen de réinstaller leur système windows en mode legacy (je ne sais pas si on peut changer en legacy un système windows déjà installé en mode EFI ou s’il est possible de passer temporairement en mode legacy car toutes les machines ne respectent pas les standards EFI et legacy de la même façon)

Mais s’il n’y a encore aucun système installé en mode EFI sur la machine et que le mode legacy est possible, on peut installer tout un tas de systèmes Linux sur la même machine en mode legacy <=> pas besoin de signature(s)

La machine que j’utilise en ce moment a un système Windows 10 qui y avait été installé en mode legacy, et j’ai 6 systèmes linux installés en plus sur cette même machine en mode legacy <=> sans problèmes de signatures.

Voilà le choix que j’ai au démarrage de ma machine (Lenovo ThinkPad T450) :

Ceci dit, il existe aussi des machines sur lesquelles c’est impossible car on n’a pas le choix entre EFI ou legacy ou sur lesquelles le mode legacy n’existe pas ou ne respecte pas certains standards, mais elles sont (pour l’instant) encore assez rares.

#16

Bonjour,

Merci pour le complément d’information qui me rappelle à quel point j’ai galéré pour installer D11 sur mon autre PC. Et d’ailleurs, je ne sais pas pourquoi ça fonctionne.

Pour ma part, je ne conserve le Windows installé que pendant la durée de garantie matérielle, parce que le service après-vente du vendeur se fera un plaisir de la refuser si seul un linux est installé sur le système.

Cordialement.

#17

En effet, le mode EFi est plus destiné à des machiens dont la securité doit etrfe plus importante, le legacy etant moins bon.

#18

http://www.pc-boost.com/pages/news_1643873161_une-societe-de-securite-avertit-que-ces-failles-de-securite-majeures-du-bios-uefi-affectent-des-millions-d-appareils.html

Je n’ai pris que 9 des plus récents des liens très rapidement trouvés.

#19

OUi le problème c’est la securité du boot efi, mais si tu veux avoir certains actifs de sécurité tu es obligé d’etre en efi, c’est justement ça le probleme.
Les disques chiffrés permettent de palier au problème indirectement. Le secure boot en est un autre. Après les puces type Titan peuvent aussi aider.
Pour faie simple, appliquer la stratégie de défense en profondeur: ne pas se contenter d’une seule ligne de défense mais de plusieurs.
En fait les articles perlent à peu prêt tous de la même chose.
C’est le code UEFI qui est en cause,mais les article parlent d’un materiel ou un autre,d’entreprises ou d’autres.
Comme c’est à peu prêt le même code partout, l’importante quantité de machines concernées est logique.
Ceci dit aussi, ce n’est pas forcément aisé de l’exploiter. Car qui dit faille, ne dit pas toujorus exploitation de cette faille, et qui dit exploitation ne dit pas facilité non plus.
Une des dernière faille de Microsoft nécessite d’avoir accès à la machine physiquement, donc cela réduit la surface d’exposition.

#20

J’ai lu sur des forums (peut-être ici) que certains paramètres du noyau peuvent améliorer la stabilité du pilote nouveau, mais je ne les ai plus en tête.

EDIT: J’ai retrouvé init_on_alloc=0 mais il me semble qu’il y en a un autre.
EDIT2: L’autre paramètre mentionné est no_console_suspend mais je ne sais pas s’il est vraiment utile ou ne sert que pour le débogage

Les performances d’affichage vont être abominables avec le pilote générique VESA.
Est-ce le seul GPU ou y a-t-il un GPU intégré au chipset ou au CPU ? Dans ce cas il vaudrait mieux utiliser le GPU intégré avec les pilotes optimisés qui offriraient de biens meilleures performances.

Concernant l’UEFI, quelques mises au point.

En effet, cela concerne tout noyau ou module du noyau compilé localement, notamment les pilotes propriétaires virtualbox, r8168 pour cartes réseau Realtek, wl pour cartes wifi Broadcom…

Ni en mode UEFI sans secure boot. Apparemment il y a une certaine confusion entre secure boot et UEFI. Le secure boot n’est qu’une fonctionnalité optionnelle de l’UEFI.

L’UEFI en lui-même n’apporte aucune sécurité. C’est le secure boot qui apporte une certaine (très relative) sécurité.

C’est très grossièrement résumé mais assez vrai en pratique.
La théorie : le système doit être signé avec une clé reconnue par le firmware UEFI.
La pratique : les firmwares UEFI ne reconnaissent que la clé de Microsoft. Certains permettent d’enregistrer d’autres clés mais ce n’est pas toujours le cas.

Mais il n’est pas forcément nécessaire de laisser le secure boot activé (ça peut l’être, j’ai vu bitlocker bloquer le démarrage de Windows si le secure boot avait été désactivé).

Non, on peut seulement faire l’inverse, ce qui va au passage entraîner une conversion de la table de partition du disque système au format GPT (et probablement casser les éventuels autres systèmes présents).

Si tu veux dire passer en mode legacy pour booter Linux ou en mode EFI pour booter Windows, c’est possible du moment que le firmware UEFI supporte l’amorçage legacy.

Pas besoin de signature non plus en mode EFI sans secure boot. Et les systèmes ne s’écraseront pas le GRUB les uns des autres dans le MBR (par contre ils s’écraseront quand même le GRUB s’il sont de la même distribution).

Non, c’est le secure boot qui est censé apporter une sécurité, pas l’UEFI en lui-même.

Le chiffrement du disque ne répond pas au mêmes risques. Même avec un disque chiffré, l’amorçage lui-même n’est pas chiffré. Le secure boot a précisément pour but de protéger l’amorçage, mais pas ce qui se passe après. Les deux sont donc complémentaires.

#21

Mais il ne me semble pas que le mode legacy permette le secure boot, non?

Non effectivement mais ca contribue à améliorer la securité en profondeur et donc de rendre un faille d’une autre couche inexploitable ou très difficile à exploiter.
l’amorçage n’est certes pas sécurisé, mais l’un des exploit les plus important c’est de pouvoir installer des executables ou autre sur le disque, ce qui ne pourra pas se faire sur un disque chiffré.

#22

Qu’est-ce qui n’est pas clair dans « Le secure boot n’est qu’une fonctionnalité optionnelle de l’UEFI » ?

Justement si car les fichiers servant à l’amorçage (chargeur, noyau, initramfs) ne sont pas chiffrés.

#23

mais tu ne pourras pas modifier le système sans le mot de passe la clef ou le certificat qu va bien. Tu ne pourra que tricher sur le démarrage d’un système, mais pas modifier celui qui est chiffré

#24

Un attaquant ayant un accès physique peut modifier à sa guise le chargeur d’amorçage, l’image du noyau et l’initramfs. C’'est suffisant pour ensuite faire faire ce qu’il veut au système lorsqu’il sera démarré et déchiffré par son utilisateur légitime, comme intercepter la clé de chiffrement, installer un rootkit ou un cheval de Troie…

#25

il lui faut donc déjà avoir un accès physique, ce qui limite pas mal les possibilités.

#26

Pour rappel, si le risque d’accès physique n’existe pas le chiffrement du disque ne sert à pas à grand-chose.

#27

Sur une machine multiboot si.
Ou sur un host hyperviseur, car il est difficile de chiffrer le host (je ne suis même pas sur que ce soit possible).

#28

Au lieu d’accès physique j’aurais plutôt dû écrire accès au disque sans passer par l’OS, ce qui inclut également l’ accès par l’hyperviseur ou par un autre OS.

#29

Et le plus comique dans cette histoire de virus et d’UEFI secure boot, c’est de constater que, le plus souvent, ce sont des applications signées par Microsoft lui même qui sont utilisées comme vecteurs de propagation par ces virus.

Il n’y a qu’à aller voir de temps en temps : https://www.cert.ssi.gouv.fr/

#30

Le problème c’est qu’il y a des machines pour lesquelles seul l’UEFI est disponible,il n’y a même pas de legacy

#31

Quel rapport avec la choucroute ?