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

**URL:** <https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844>\
**Category:** Support Debian\
**Created:** [Juillet 21, 2022, 2:16 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844 "2022-07-21T14:16:47Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 23, 2022, 11:18 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/21 "2022-07-23T11:18:41Z")

</div>

> [@PascalHambourg](#):
>
> Non, c’est le secure boot qui est censé apporter une sécurité, pas l’UEFI en lui-même.

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

> [@PascalHambourg](#):
>
> 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.

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é.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Juillet 23, 2022, 11:23 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/22 "2022-07-23T11:23:24Z")

</div>

> [@Zargos](#):
>
> Mais il ne me semble pas que le mode legacy permette le secure boot, non?

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

> [@Zargos](#):
>
> 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é

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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 24, 2022, 1:58 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/23 "2022-07-24T13:58:20Z")

</div>

> [@PascalHambourg](#):
>
> Justement si car les fichiers servant à l’amorçage (chargeur, noyau, initramfs) ne sont pas chiffrés.

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é

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Juillet 24, 2022, 3:25 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/24 "2022-07-24T15:25:00Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 24, 2022, 4:04 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/25 "2022-07-24T16:04:32Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Juillet 24, 2022, 4:44 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/26 "2022-07-24T16:44:14Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 24, 2022, 4:49 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/27 "2022-07-24T16:49:47Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Juillet 24, 2022, 4:56 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/28 "2022-07-24T16:56:52Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Juillet 24, 2022, 5:00 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/29 "2022-07-24T17:00:19Z")

</div>

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/](https://www.cert.ssi.gouv.fr/)

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Juillet 24, 2022, 5:03 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/30 "2022-07-24T17:03:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Juillet 24, 2022, 7:53 UTC](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844/31 "2022-07-24T19:53:43Z")

</div>

Quel rapport avec la choucroute ?

[Page précédente](https://www.debian-fr.org/t/xorg-generique-pour-carte-nvidia-plus-supportee/86844.md?page=1)
