Upgrade to Pro — share decks privately, control downloads, hide ads and more …

100 % open source, au-dessus de cette ligne

Avatar for Poddingue Poddingue
October 27, 2026

100 % open source, au-dessus de cette ligne

Vous feriez confiance à une machine dont vous ne contrôlez pas le démarrage ? On colle « 100 % open source » sur une infra comme un sticker sur un capot, et personne ne soulève le capot. Faisons-le. Lançons un strace sur la promesse et descendons, couche par couche, d’une VM jusqu’au silicium, en notant à chaque étage si le code est vraiment ouvert : vert, orange, rouge.

L’hyperviseur et la toolstack (Xen, XCP-ng) ? Vert : lisible, auditable, tout va bien. L’UEFI, le bootloader, le BMC ? Orange : coreboot et OpenBMC existent… que quasiment personne ne fait tourner. Et puis on descend encore, et là on rencontre l’Intel ME et l’AMD PSP. Surprise : il y a un CPU dans votre CPU, il ne vous demande pas votre avis, et il a plus de droits que votre hyperviseur. Fermé, non auditable, impossible à retirer. Rouge vif, le genre de rouge qui mine notre espoir.

Bonne nouvelle pour finir : le bas de la pile s’ouvre enfin, avec RISC-V et OpenSBI, un terrain sur lequel je bricole concrètement en amont. L’open source est une direction, pas une case à cocher.

Avatar for Poddingue

Poddingue

October 27, 2026

More Decks by Poddingue

Other Decks in Technology

Transcript

  1. 100 % open source 🚌 ↑ au-dessus de cette ligne

    Bruno Verachten · Cloud Nord 2026 · Lille 1
  2. Un bus. Une grotte. Une carte SIM. Oslo descend deux

    bus électriques au fond d'une grotte Le neuf peut recevoir des mises à jour à distance, via une SIM roumaine Le vieux, non En théorie, le neuf peut être arrêté à distance 100 % open source — au-dessus de cette ligne · @poddingue Photo : Ruter AS 2
  3. Vos serveurs ont la même question A B BMC (iDRAC,

    iLO…) ? dedans ? ✋ Qui a déjà ouvert ✋ Qui a déjà lu le l'interface web d'un code qui tourne 100 % open source — au-dessus de cette ligne · @poddingue 3
  4. Bruno Verachten Community manager chez Vates (XCP-ng, Xen Orchestra) Cloud

    Nord 2025 : des téléphones Android en agents Jenkins Du côté pratique de RISC-V 100 % open source — au-dessus de cette ligne · @poddingue 4
  5. Dans 45 minutes, vous saurez… ce que vous pouvez lire,

    patcher, ou seulement croire quoi faire lundi matin pourquoi la ligne descend enfin 100 % open source — au-dessus de cette ligne · @poddingue 5
  6. On descend. vous votez audit() = 0 · lisible ·

    = ? · en partie · = -1 EACCES · fermé 6
  7. 🛗0 Tout va bien ? 0 ? vous êtes ici

    ? −1 ? −2 ? −3 ? −4 7
  8. Votre hyperviseur open source ? A 🟢= 0 lisible 100

    % open source — au-dessus de cette ligne B 🟠= ? en partie · C 🔴= -1 EACCES fermé @poddingue 8
  9. audit("hyperviseur") = 0 · lisible Tout va bien. Votre VM

    : votre code, votre OS Xen, KVM : GPL, code public, patchable 100 % open source — au-dessus de cette ligne · @poddingue 9
  10. audit("démarrage XCP-ng") = ? · en partie Secure Boot activé

    ? L'hôte ne démarre pas. Ni l'installeur, ni l'hôte installé Il faudrait un certificat Microsoft All bootable devices failed Secure Boot verification. 100 % open source — au-dessus de cette ligne · @poddingue 11
  11. 🛗 −1 Toc toc. Il y a quelqu'un ? 0

    = 0 VM · hyperviseur · toolstack −1 ? vous êtes ici ? −2 ? −3 ? −4 12
  12. Le firmware UEFI de vos serveurs ? A 🟢= 0

    lisible 100 % open source — au-dessus de cette ligne B 🟠= ? en partie · C 🔴= -1 EACCES fermé @poddingue 13
  13. audit("uefi") = ? · en partie La porte existe UEFI

    constructeur : binaire fermé coreboot : le minimum, puis un payload (SeaBIOS, GRUB, TianoCore) 100 % open source — au-dessus de cette ligne · @poddingue 14
  14. Ouvert, mais sur quel matériel ? Libreboot : le moins

    de blobs possible… surtout sur du matériel ancien Le matériel récent démarre avec du code du fondeur Dasharo (coreboot) : préinstallé ou par abonnement. Le ME ou le PSP restent là. audit("uefi") = ? · en partie 100 % open source — au-dessus de cette ligne · @poddingue 15
  15. Arrêté. Pas retiré. Dasharo, menu Intel ME : « Disabled

    (HAP) » arrête le ME. Il reste en flash. Capture : 3mdeb · documentation Dasharo · Apache-2.0 16
  16. 🛗 −2 Toc toc. Il y a quelqu'un ? 0

    = 0 −1 = ? VM · hyperviseur · toolstack UEFI · bootloader −2 ? vous êtes ici ? −3 ? −4 17
  17. Le BMC, ça vous parle ? A B ✋ Qui

    a déjà mis à jour le firmware de ✋ Qui sait quel OS son BMC ? tourne dedans ? 100 % open source — au-dessus de cette ligne · @poddingue 18
  18. audit("bmc") = ? · en partie Votre serveur a une

    carte SIM, lui aussi Allumer, éteindre, console, ISO… même serveur éteint Son propre OS, son propre réseau iDRAC, iLO, XClarity, iRMC, Supermicro : propriétaires par défaut 100 % open source — au-dessus de cette ligne · @poddingue 19
  19. OpenBMC existe. Qui s'en sert ? Une distribution Linux open

    source pour BMC Pas disponible partout Et quand elle l'est… audit("bmc") = ? · en partie 100 % open source — au-dessus de cette ligne · @poddingue 20
  20. OpenBMC, carte Bletchley, dans QEMU $ ssh bmc [email protected]'s password:

    root@bletchley:~# grep -E '^(NAME|VERSION_ID|OPENBMC_TARGET_MACHINE)=' /etc/os-release NAME="Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro)" VERSION_ID=3.1.0-dev-1634-g6f3fe60ca2 OPENBMC_TARGET_MACHINE="bletchley" root@bletchley:~# uname -sr Linux 6.18.58-fe9d9b9 root@bletchley:~# Image OpenBMC publique pour Bletchley (Meta) · émulée sur mon portable · 26/10/2026 Capture : Bruno Verachten 21
  21. 🛗 −3 Toc toc. Il y a quelqu'un ? 0

    = 0 −1 = ? −2 = ? VM · hyperviseur · toolstack UEFI · bootloader BMC −3 ? vous êtes ici ? −4 22
  22. Combien de processeurs dans ce serveur ? A 1 B

    C 2 3 ou plus 100 % open source — au-dessus de cette ligne · @poddingue D Je ne veux pas savoir Photo : Jemimus · CC BY 2.0 23
  23. Intel ME · AMD PSP ? A 🟢= 0 lisible

    100 % open source — au-dessus de cette ligne B 🟠= ? en partie · C 🔴= -1 EACCES fermé @poddingue 25
  24. audit("intel_me") = -1 EACCES · fermé L'Intel Management Engine Un

    ordinateur séparé, dans le chipset, depuis 2006 Firmware signé par Intel, obligatoire Sans firmware valide, extinction au bout de… 30 minutes. 100 % open source — au-dessus de cette ligne · @poddingue 26
  25. audit("amd_psp") = -1 EACCES · fermé AMD PSP : pas

    de jaloux Un cœur ARM, sur la même puce que vos cœurs x86 Firmware signé par AMD Sans lui, vos cœurs x86 ne démarrent pas 100 % open source — au-dessus de cette ligne · @poddingue 27
  26. audit() = -1 EACCES · fermé J'ai regardé : un

    vrai EPYC Genoa PSP : fusibles, debug, anti-rollback : verrouillé Secure Boot : aucune clé enrôlée Pas de TPM · fwupd : HSI:0 (échelle de 0 à 5) Au moins 10 firmwares dans la machine 100 % open source — au-dessus de cette ligne · @poddingue 28
  27. audit() = -1 EACCES · fermé Et chez Intel ?

    Mon NUC Intel ME (CSME 18.1) : verrouillé Boot Guard : clé d'ASUS gravée dans les fusibles TPM 2.0 · clés Secure Boot : ASUS et Microsoft fwupd : HSI:3 sur 5. Meilleure note… et plus de verrous 100 % open source — au-dessus de cette ligne · @poddingue 29
  28. Qui est root, vraiment ? 3 · vos applis 2

    1 0 · noyau Vers le centre : plus de droits. L'intérieur voit l'extérieur. Pas l'inverse. −1 hyperviseur Intel, manuel du développeur, vol. 3A, § 5.5 : 4 niveaux, de 0 à 3 30
  29. Qui est root, vraiment ? 3 · vos applis 2

    1 0 · noyau −1 hyperviseur Vers le centre : plus de droits. L'intérieur voit l'extérieur. Pas l'inverse. ME · PSP −2, −3 un autre processeur « Ring −2, −3 » : une façon de parler (Libreboot) 31
  30. Il y a un CPU dans votre CPU. …et c'est

    lui le patron. Photo : Martijn Boer · domaine public 32
  31. « Mais il y a me_cleaner ! » Retire une

    partie du firmware ME Le bit HAP l'arrête après le démarrage AMD PSP : pas d'équivalent 100 % open source — au-dessus de cette ligne · @poddingue 33
  32. 🛗 −4 Toc toc… 0 = 0 −1 = ?

    −2 = ? VM · hyperviseur · toolstack UEFI · bootloader BMC −3 = -1 Intel ME · AMD PSP −4 ? vous êtes ici 34
  33. audit("isa_x86") = -1 EACCES · fermé Le fond de la

    grotte (x86) Jeu d'instructions x86 : propriétaire Conception des cœurs : secrète Pas une loi de la physique : OpenPOWER, RISC-V documentent le leur 100 % open source — au-dessus de cette ligne · @poddingue 35
  34. 🛗 Remontée express VM · hyperviseur · toolstack audit() =

    0 · lisible UEFI · bootloader audit() = ? · en partie BMC audit() = ? · en partie Intel ME · AMD PSP audit() = -1 EACCES · fermé ISA · silicium (x86) audit() = -1 EACCES · fermé 100 % open source — au-dessus de cette ligne · @poddingue 36
  35. Étage bonus : le disque. « Chiffré », vraiment ?

    Votre SSD a son propre processeur et son firmware fermé 2019 : des SSD auto-chiffrants lus sans le mot de passe La promesse « chiffré » vivait dans un firmware non auditable 100 % open source — au-dessus de cette ligne · @poddingue Illustration : Tom Cowap · CC BY-SA 4.0 37
  36. La ligne bouge. Dans les deux sens. 2015 : nouvelles

    règles de sécurité radio de la FCC TP-Link verrouille : plus de firmware tiers 2016 : 200 000 $, et l'engagement de rouvrir la porte 100 % open source — au-dessus de cette ligne · @poddingue Illustration : Sylvain Leroux, d'après David Vignoni · LGPL 38
  37. Lundi matin on ne rend pas le rouge vert, on

    le rend visible Photo : Daniel Gomez · Unsplash 40
  38. 1. Inventorier fwupdmgr get-devices dmidecode -t bios # firmwares vus

    par fwupd # version du firmware système Vous connaissez le digest de vos images. Et la version de vos firmwares ? 100 % open source — au-dessus de cette ligne · @poddingue Photo : Rana Kaname · Unsplash 41
  39. 2. Mesurer Secure Boot : le videur, il refuse Measured

    boot : la caméra, elle enregistre dans le TPM tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements 100 % open source — au-dessus de cette ligne · @poddingue Photo : Collin · Unsplash 42
  40. [DÉMO] Qu'estce qui a démarré ? Ce que fwupd voit

    Ce que le TPM a enregistré Un réglage change… on cherche la différence 100 % open source — au-dessus de cette ligne · @poddingue 43
  41. Premier démarrage root@grml:~# ./demo.sh show avant #1 PCR0 S_CRTM_CONTENTS #2

    PCR0 S_CRTM_VERSION #3 PCR0 POST_CODE #4 PCR7 EFI_VARIABLE_DRIVER_CONFIG #5 PCR7 EFI_VARIABLE_DRIVER_CONFIG #6 PCR7 EFI_VARIABLE_DRIVER_CONFIG #7 PCR7 EFI_VARIABLE_DRIVER_CONFIG #8 PCR7 EFI_VARIABLE_DRIVER_CONFIG #9 PCR7 SEPARATOR #10 PCR6 COMPACT_HASH #11 PCR6 COMPACT_HASH #12 PCR6 COMPACT_HASH #13 PCR1 EFI_HANDOFF_TABLES #14 PCR1 EFI_HANDOFF_TABLES #15 PCR1 EFI_HANDOFF_TABLES #16 PCR1 EFI_HANDOFF_TABLES #17 PCR1 PLATFORM_CONFIG_FLAGS #18 PCR0 SEPARATOR #19 PCR1 SEPARATOR #20 PCR2 SEPARATOR #21 PCR3 SEPARATOR #22 PCR4 SEPARATOR #23 PCR5 SEPARATOR #24 PCR6 SEPARATOR #25 PCR5 EFI_GPT_EVENT #26 PCR1 EFI_VARIABLE_BOOT #27 PCR1 EFI_VARIABLE_BOOT #28 PCR1 EFI_VARIABLE_BOOT #29 PCR1 EFI_VARIABLE_DRIVER_CONFIG #30 PCR1 EFI_VARIABLE_DRIVER_CONFIG #31 PCR1 EFI_HANDOFF_TABLES #32 PCR4 EFI_BOOT_SERVICES_APPLICATION #33 PCR4 EFI_BOOT_SERVICES_APPLICATION #34 PCR9 EVENT_TAG #35 PCR9 EVENT_TAG Boot Guard Measured S-CRTM blob @0xff6e1000 (6483968 B) SecureBoot PK KEK db dbx ──── Dell Configuration Information 1 Dell Configuration Information 1 Dell Configuration Information 2 ──── ──── ──── ──── ──── ──── ──── EFI PART BootOrder Boot0002 Boot0001 DeployedMode AuditMode \EFI\BOOT\BOOTX64.EFI (image in memory) LOADED_IMAGE::LoadOptions Linux initrd 9fea3180c756 d4720b400943 34e1c9c69b1d ce9ce386b52e 2abfe9865a65 63a525134bfb ad1850a48856 27f317879c70 df3f619804a9 c41a932f6374 908b81a2e1ed 952b92ff29d7 0f57271e82d0 9c844a8fe22e c71417f1f28a 75b9b4513813 03456420f070 df3f619804a9 df3f619804a9 df3f619804a9 df3f619804a9 df3f619804a9 df3f619804a9 df3f619804a9 2209e5679a83 b8c05d01fb1e 6f503efe1705 797b800fd845 082271255dcc b70b7c1b9220 4ae369a7a4ce 5e7391b140d0 c925e790ef5f 5a2e6c286490 de0ad364f67f Dell OptiPlex du labo · démarré sur GRML · enregistré le 27/09/2026 44
  42. Second démarrage root@grml:~# grep BootOrder lab/avant/efibootmgr.txt lab/apres/efibootmgr.txt lab/avant/efibootmgr.txt:BootOrder: 0002,0001 lab/apres/efibootmgr.txt:BootOrder:

    0001,0002 root@grml:~# ./demo.sh diff avant apres - #26 PCR1 EFI_VARIABLE_BOOT BootOrder + #26 PCR1 EFI_VARIABLE_BOOT BootOrder + #27 PCR1 EFI_VARIABLE_BOOT Boot0001 - #28 PCR1 EFI_VARIABLE_BOOT Boot0001 35 → 35 events · 2 removed · 2 added b8c05d01fb1e 9eb8777d0a1a 797b800fd845 797b800fd845 Même machine · un seul réglage changé : l'ordre de boot, inversé dans le firmware 45
  43. 3. Attester Comparer les mesures à une politique connue, depuis

    ailleurs Keylime : projet CNCF Du zero trust… jusqu'au firmware 100 % open source — au-dessus de cette ligne · @poddingue Photo : Raymond Petrik · Unsplash 46
  44. 4. Épingler Pas de :latest pour vos images. Ni pour

    votre firmware. fwupd et LVFS quand c'est possible Demandez un SBOM firmware à vos fournisseurs 100 % open source — au-dessus de cette ligne · @poddingue Photo : Immo Wegmann · Unsplash 47
  45. 5. Isoler Réseau de management séparé. Jamais la prod. Accès

    restreint, comptes par défaut changés OpenBMC, là où le matériel le permet 100 % open source — au-dessus de cette ligne · @poddingue Photo : Roberto Nickson · Unsplash 48
  46. Et si vos serveurs sont chez quelqu'un d'autre ? Les

    étages −1 à −4 sont toujours là. Les clés ne sont plus chez vous. vTPM : Shielded VM, NitroTPM, Trusted Launch Confidential VM (SEV-SNP, TDX) : mémoire chiffrée par le matériel Demandez : qui met à jour le firmware de mes hôtes ? Avec quelle preuve ? 100 % open source — au-dessus de cette ligne · @poddingue 49
  47. La ligne bouge le bas de la pile commence à

    s'ouvrir Photo : Igor Sporynin · Unsplash 51
  48. 🛗 Même ascenseur, autre immeuble : RISC-V VM · hyperviseur

    · toolstack audit() = 0 · lisible UEFI · bootloader audit() = ? · en partie BMC audit() = ? · en partie OpenSBI : sous l'OS ISA · le cœur : ça dépend 100 % open source — au-dessus de cette ligne · audit() = 0 · lisible = 0 = ? @poddingue 52
  49. audit() = ? · en partie Et sur RISC-V ?

    Ma Banana Pi F3 Chargeur, init mémoire, U-Boot : GPL, commit exact OpenSBI : un fork, pas l'amont Un 2ᵉ cœur exécute esos.elf : précompilé … dont la source est publiée 100 % open source — au-dessus de cette ligne · @poddingue 53
  50. Une ISA ouverte n'est pas un cœur ouvert P550 :

    vendu sous licence, comme IP : fermé CVA6 : plans du cœur (RTL) publiés, démarre Linux : ouvert … mais outils de synthèse fermés. L'extension hyperviseur ? Dans le RTL, depuis la 5.1.0 audit("cva6") = ? · en partie 100 % open source — au-dessus de cette ligne · @poddingue Photo : Maksym Kaharlytskyi · Unsplash 54
  51. 16 cœurs. Enfin… 8. Un hyperviseur doit virtualiser le CPU

    (H), les interruptions (AIA), les périphériques (IOMMU) SpacemiT K3 : les trois annoncés Mais seuls 8 cœurs sur 16 ont l'extension H Mesuré sur une carte : AIA oui, IOMMU invisible pour Linux 100 % open source — au-dessus de cette ligne · @poddingue Photo : John Matychuk · Unsplash 55
  52. Xen sur RISC-V, en amont Le port RISC-V avance dans

    le dépôt principal Code commun d'abord, le moins de spécifique possible Je ne porte pas Xen. Je porte tout ce qu'il y a autour, jusqu'à ce que ça compile sur riscv64. audit("bruno") = ? · fan-boy 100 % open source — au-dessus de cette ligne · @poddingue Vidéo : Baptiste Le Duc · 2026-10-23 · émulé (QEMU sur x86) 56
  53. Ce qui manque encore Xen RISC-V : pas encore de

    pilote IOMMU matériel Donc pas encore de passthrough Un serveur RISC-V complet dans vos baies lundi ? Non. audit("v100") = ? · annoncée, pas livrée audit("ber10") = ? · silicium, détails non publiés 100 % open source — au-dessus de cette ligne · @poddingue Photo : Ludovic [nom] · RVI Summit China 2026 57
  54. Des switches à l'abandon Christopher Wright rétro-conçoit du silicium Broadcom

    à l'établi · github.com/Salvaged-silicon/nosaic-switch « Nothing is production yet. » Illustration : ifish · CC0 58
  55. « Vous feriez confiance à une machine dont vous ne

    contrôlez pas le démarrage ? » 100 % open source — au-dessus de cette ligne · @poddingue 59
  56. Ce qu'on a fait ensemble Descendu de la VM au

    silicium, en votant Trouvé le patron : Intel ME, AMD PSP 5 verbes pour lundi · la ligne descend Slides et sources : speakerdeck.com/gounthar · Votre avis : à droite 61
  57. Sources Chaque affirmation des slides, avec sa source. Pour chaque

    slide (numéro et titre), les références citées : l'affirmation, l'adresse de la source, son niveau et le verdict. Niveau 1 : le document lui-même (code, documentation officielle, publication primaire). 2 : presse avec rédaction et correctifs. 3 : presse spécialisée. 4 : partie intéressée (constructeur, marketing). 5 : non attribué. Une source de niveau 4 ou 5 plafonne le verdict à « plausible ». Les mesures de l'auteur ont été faites sur ses propres machines ; leurs relevés bruts ne sont pas publiés quand ils contiennent des numéros de série.
  58. 2 Un bus. Une grotte. Une carte SIM. R01 Ruter

    (Oslo) tested a new Yutong e-bus and a 3-year-old VDL bus in an isolated environment inside a mountain (« inne i et fjell »); the Yutong's OTA channel gives the manufacturer digital access to the battery/power-supply control system via a Romanian SIM, so in theory the bus could be stopped or disabled remotely; the VDL bus has no OTA capability https://ruter.no/nyheter/ruter-med-omfattende-sikkerhetstest-av-elektriske-busser niveau 1 · confirmé · vérifié le 2026-09-26 R04 Danish operator Movia commissioned EY to independently risk-assess cybersecurity across 7+ EV bus/vehicle manufacturers (incl. Chinese ones) serving its routes; EY found no basis to consider Chinese buses less cybersecure than other manufacturers, and in fact the Dutch manufacturer (VDL) scored the lowest documented cybersecurity maturity of the group (10% governance, 0% risk analysis) against Yutong's near-complete scores (100%/95%/100%/100%/100%/93%) https://www.moviatrafik.dk/media/3topzxnw/risk-assessment-of-cybersecurity-for-ev-bus-and-ev-vehicles____final-2296728_-1.pdf https://via.ritzau.dk/pressemeddelelse/15161742/elbusser-overholder-lovregulering-af-cybersikkerhed niveau 1 · confirmé · vérifié le 2026-09-26 I01 Ruter's photo of the Yutong bus in the cave inside the mountain (YUTONG badge, plate, Ruter marks blurred; darkened) https://cdn.sanity.io/images/5a84xxkm/prod/bb1a0b7a732a62a68210118c90bf8e0124668bac-6240x4160.jpg image · licence : © 2025 Ruter AS, no licence on the page 4 Bruno Verachten R79 Bruno Verachten a parlé à Cloud Nord 2025 https://2025.cloudnord.fr/speakers/cmc0tyyuc07mepc3mzyjfvfuv niveau 1 · confirmé · vérifié le 2026-10-21
  59. 9 Tout va bien. L01 Hypervisor + toolstack (Xen, XCP-ng)

    are GPL-licensed, source published, auditable and patchable https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=COPYING https://github.com/xcp-ng/xcp niveau 1 · confirmé · vérifié le 2026-09-26 R80 KVM est sous GPL, code public, dans le noyau Linux https://github.com/torvalds/linux/blob/master/virt/kvm/kvm_main.c https://github.com/torvalds/linux/blob/master/COPYING niveau 1 · confirmé · vérifié le 2026-10-21 11 Secure Boot activé ? L'hôte ne démarre pas. R41 Notes de version XCP-ng 8.1 : « support for Secure Boot is NOT INCLUDED because it relies on proprietary packages » https://docs.xcp-ng.org/releases/release-8-1/ niveau 1 · confirmé · vérifié le 2026-09-26 R42 Réponse du projet sur le forum : compatibilité Secure Boot = il faudrait un certificat Microsoft valide https://xcp-ng.org/forum/topic/8485 niveau 1 · confirmé · vérifié le 2026-09-26 R43 Labo de Bruno : OptiPlex 7060, XCP-ng 8.3, Secure Boot on → « All bootable devices failed Secure Boot verification », installeur et hôte installé ; ISO aussi corrompue au début Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-07-31 R44 Secure Boot des VMs supporté : uefistored depuis 8.2.1 (puis varstored en 8.3+), certificats stockés côté hôte et copiés dans le magasin EFI de chaque VM à son premier démarrage ; une mise à jour des certificats du pool ne se propage pas automatiquement aux VMs déjà initialisées https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/ niveau 1 · confirmé · vérifié le 2026-09-26
  60. R86 L'hyperviseur installé sur ce serveur ne sait pas encore

    démarrer l'hôte en Secure Boot ; c'est en cours https://github.com/xcp-ng/xcp/issues/294 https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/ niveau 1 · confirmé · vérifié le 2026-10-22 R92 La spécification UEFI permet d'enrôler sa propre clé de plateforme (PK) : sans PK, la plateforme est en « setup mode » et la PK peut être écrite ; ensuite seul le détenteur de la PK peut la changer https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html niveau 1 · confirmé · vérifié le 2026-10-22 14 La porte existe L02 UEFI/bootloader: vendor UEFI is largely closed firmware; open replacements exist — TianoCore/EDK2 (BSD-2-Clause-Patent, reference UEFI implementation), coreboot (minimal init + open payload), Libreboot (deblobbed coreboot config, narrow hardware support), Dasharo (corebootbased, built by 3mdeb, shipped on NovaCustom laptops) https://github.com/tianocore/edk2 https://github.com/tianocore/edk2/blob/master/License.txt https://doc.coreboot.org/ https://libreboot.org/faq.html https://dasharo.com/ niveau 1 · confirmé · vérifié le 2026-09-26 R122 Faille critique (pré-démarrage, exécution de code) dans le pilote PXE d'EDK2, l'implémentation de référence d'UEFI ; avis publié le 2026-10-22, correctif public depuis le 2026-10-15 ; sur un serveur, il arrive avec un nouveau firmware du constructeur https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m https://github.com/tianocore/edk2/commit/560ed9b5b1 niveau 1 · confirmé · vérifié le 2026-10-28
  61. 15 Ouvert, mais sur quel matériel ? L02 UEFI/bootloader: vendor

    UEFI is largely closed firmware; open replacements exist — TianoCore/EDK2 (BSD-2-Clause-Patent, reference UEFI implementation), coreboot (minimal init + open payload), Libreboot (deblobbed coreboot config, narrow hardware support), Dasharo (corebootbased, built by 3mdeb, shipped on NovaCustom laptops) https://github.com/tianocore/edk2 https://github.com/tianocore/edk2/blob/master/License.txt https://doc.coreboot.org/ https://libreboot.org/faq.html https://dasharo.com/ niveau 1 · confirmé · vérifié le 2026-09-26 R112 Intel ME : à partir des PCH série 100, les microcontrôleurs passent d'ARCompact (ARC) à x86 : le cœur Minute IA, celui des Quark et Edison, « based on a rather old scalar Intel 486 microprocessor » avec le jeu d'instructions du Pentium ; l'OS est MINIX (avant : ThreadX). Tanenbaum confirme MINIX dans l'ME-11 mais dit l'avoir appris par la presse (même origine) https://positechglobal.com/en/research/analytics/disabling-intel-me-11-via-undocumented-mode/ https://www.cs.vu.nl/~ast/intel/ niveau 2 · confirmé · vérifié le 2026-10-26 R109 Libreboot se décrit comme une « coreboot distribution », comme Debian pour Linux ; sa « Binary Blob Reduction Policy » : code libre quand coreboot en a, code du fondeur sinon, microcode exigé, me_cleaner documenté pour l'ME. Remplace la lecture « 100 % libre » de R45 https://libreboot.org/ https://libreboot.org/news/policy.html niveau 1 · confirmé · vérifié le 2026-10-26 R45 FAQ Libreboot : sur Intel récent, l'init passe par le FSP d'Intel, quasi impossible à remplacer ; ME retiré seulement sur plateformes pré-ME 6.0 (X200, T400) https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26
  62. R46 Dasharo désactive l'Intel ME via le bit HAP :

    le firmware ME reste présent en flash, arrêté (pas retiré) https://docs.dasharo.com/osf-trivia-list/me/ niveau 1 · confirmé · vérifié le 2026-09-26 16 Arrêté. Pas retiré. R46 Dasharo désactive l'Intel ME via le bit HAP : le firmware ME reste présent en flash, arrêté (pas retiré) https://docs.dasharo.com/osf-trivia-list/me/ niveau 1 · confirmé · vérifié le 2026-09-26 I18 Capture du menu de configuration Dasharo « Intel Management Engine Options » : Intel ME mode ouvert sur Enabled, Disabled (Soft), Disabled (HAP). Agrandie ×2 au plus proche voisin (644×459 → 1288×918), sans autre retouche https://github.com/Dasharo/docs/blob/31300a0/docs/images/menus/me_menu2.jpeg image · licence : Apache-2.0 (licence du dépôt Dasharo/docs) 19 Votre serveur a une carte SIM, lui aussi L03 BMC (out-of-band management): vendor BMCs (Dell iDRAC, HPE iLO, Lenovo XClarity, Fujitsu iRMC, Supermicro) are closed; OpenBMC is the open-source alternative (started 2014-15, Facebook/IBM/Rackspace, now backed by Microsoft/Intel/IBM/Google/Facebook) https://github.com/openbmc/openbmc https://lwn.net/Articles/683583/ https://queue.acm.org/detail.cfm?id=3378404 niveau 1 · confirmé · vérifié le 2026-09-26 I02 Drawing of SIM sizes (MFF2, 4FF, 3FF, 2FF), faded, bottom right https://commons.wikimedia.org/wiki/File:SIM_card_sizes.png image · licence : CC0
  63. R123 Chez les cinq constructeurs de BMC, une partie des

    fonctions est sous licence : selon le modèle, la console graphique, le montage d'une ISO, l'envoi des logs vers un syslog, la mise à jour du BIOS à distance https://support.hpe.com/hpesc/public/docDisplay?docId=sd00002201en_us&page=GUID-ADBF291F-2960-459F-9B3C-74F1F05ECEC4.html https://www.dell.com/support/kbdoc/en-us/000176472 https://pubs.lenovo.com/xcc/NN1ia_c_enterpriselevelfeatures https://sp.ts.fujitsu.com/dmsp/Publications/public/ds-irmc-s6-en.pdf https://store.supermicro.com/out-of-band-sft-oob-lic.html niveau 1 · confirmé · vérifié le 2026-10-28 R124 Sur un serveur AMD prêté (1,5 To de DDR5), plus de quatre minutes de POST avant le début de la détection des périphériques au premier démarrage à froid, et environ quatre minutes de POST à chaque redémarrage à chaud Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-28 20 OpenBMC existe. Qui s'en sert ? L03 BMC (out-of-band management): vendor BMCs (Dell iDRAC, HPE iLO, Lenovo XClarity, Fujitsu iRMC, Supermicro) are closed; OpenBMC is the open-source alternative (started 2014-15, Facebook/IBM/Rackspace, now backed by Microsoft/Intel/IBM/Google/Facebook) https://github.com/openbmc/openbmc https://lwn.net/Articles/683583/ https://queue.acm.org/detail.cfm?id=3378404 niveau 1 · confirmé · vérifié le 2026-09-26 R110 OpenBMC : Facebook lance un projet OpenBMC en 2014 et le déploie « into production along with Wedge » (switch) ; IBM et Rackspace lancent le leur en 2015 ; après fusion, fondateurs Microsoft, Intel, IBM, Google, Facebook. En 2026, « Meta deploys directly from master each week ». Rien de trouvé sur Google ou Microsoft en production https://engineering.fb.com/2015/03/10/open-source/introducing-openbmc-an-open-software-framework-for-next-generation-system-management/ https://queue.acm.org/detail.cfm?id=3378404 https://www.ami.com/resources/inside-the-inaugural-openbmc-meetup-charting-an-open-first-future/ niveau 2 · confirmé en partie (reste : plausible) · vérifié le 2026-10-26
  64. 21 OpenBMC, carte Bletchley, dans QEMU R113 Bletchley est une

    plateforme Meta pour OpenBMC : couche meta-facebook/meta-bletchley dans openbmc/openbmc ; QEMU 10.0 la nomme « Facebook Bletchley BMC ». L'image publique obmc-phosphor-image-bletchley-20261026044328.static.mtd du Jenkins OpenBMC (latestmaster) démarre dans QEMU (-M bletchley-bmc) : os-release « Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) », VERSION_ID 3.1.0-dev-1634-g6f3fe60ca2, OPENBMC_TARGET_MACHINE bletchley ; Linux 6.18.58 ; pas d'interface web dans cette image, Redfish seulement. Ce n'est pas le firmware que Meta déploie https://github.com/openbmc/openbmc/tree/master/meta-facebook/meta-bletchley https://jenkins.openbmc.org/job/latest-master/label=docker-builder,target=bletchley/ niveau 1 · confirmé · vérifié le 2026-10-26 I19 Capture terminal : SSH vers le BMC Bletchley émulé, grep d'os-release puis uname -sr. Session réelle, enregistrée en asciicast par pty (deck/assets/casts/openbmc-bletchley.cast), dernier écran rendu par termtosvg Photo ou dessin de l'auteur, original non publié image · licence : © Bruno Verachten 23 Combien de processeurs dans ce serveur ? L03 BMC (out-of-band management): vendor BMCs (Dell iDRAC, HPE iLO, Lenovo XClarity, Fujitsu iRMC, Supermicro) are closed; OpenBMC is the open-source alternative (started 2014-15, Facebook/IBM/Rackspace, now backed by Microsoft/Intel/IBM/Google/Facebook) https://github.com/openbmc/openbmc https://lwn.net/Articles/683583/ https://queue.acm.org/detail.cfm?id=3378404 niveau 1 · confirmé · vérifié le 2026-09-26
  65. L08 SSD controllers run their own closed ARM-core firmware below

    the OS, and that firmware is itself an unauditable trust boundary: a 2018 peerreviewed study (Meijer & van Gastel, Radboud University, IEEE S&P) found firmware/debug-interface flaws in several Crucial and Samsung selfencrypting SSDs (CVE-2018-12037, CVE-2018-12038) that let an attacker recover data without the user's password — the "encrypted" guarantee lived entirely in unauditable controller firmware https://www.ieee-security.org/TC/SP2019/papers/310.pdf niveau 1 · confirmé · vérifié le 2026-09-26 L09 Hidden/unsigned firmware is not confined to ME/PSP/SSD — peripheral controllers (WiFi/NIC adapters, USB hubs, trackpads, cameras) on majorvendor laptops (Lenovo, Dell, HP) were found running unsigned firmware, each a further unaudited compute surface https://eclypsium.com/wp-content/uploads/Eclypsium-Unsigned-Peripheral-Firmware-Research-1.pdf niveau 4 · plausible · vérifié le 2026-09-26 I03 IBM xSeries 336 mainboard, a 1U server with the lid off (lightened) https://commons.wikimedia.org/wiki/File:Mainboard_of_an_xseries_336_-_IMG_3453.jpg image · licence : CC BY 2.0 26 L'Intel Management Engine R112 Intel ME : à partir des PCH série 100, les microcontrôleurs passent d'ARCompact (ARC) à x86 : le cœur Minute IA, celui des Quark et Edison, « based on a rather old scalar Intel 486 microprocessor » avec le jeu d'instructions du Pentium ; l'OS est MINIX (avant : ThreadX). Tanenbaum confirme MINIX dans l'ME-11 mais dit l'avoir appris par la presse (même origine) https://positechglobal.com/en/research/analytics/disabling-intel-me-11-via-undocumented-mode/ https://www.cs.vu.nl/~ast/intel/ niveau 2 · confirmé · vérifié le 2026-10-26 R67 Intel ME : sans firmware ME valide, la machine s'éteint au bout de 30 minutes (watchdog) — « d'après ceux qui l'ont démonté » https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26
  66. L05 Intel ME / AMD PSP: closed, cryptographically-signed firmware on

    a coprocessor with more privilege than the hypervisor; cannot be removed (post-Nehalem systems force-shutdown after ~30 min without valid ME firmware); Intel's own 2017 advisory (INTEL-SA-00086) confirms remotely-exploitable and local-privilege-escalation flaws in ME/TXE/SPS across 1st-8th gen Intel Core and Xeon E3 v5/v6 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html https://www.cisa.gov/news-events/alerts/2017/11/21/intel-firmware-vulnerability niveau 1 · confirmé · vérifié le 2026-09-26 R47 FAQ Libreboot : ME présent sur les machines Intel depuis 2006 ; depuis Nehalem (ME 6.0) il fait une partie de l'init matériel https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26 27 AMD PSP : pas de jaloux L07 AMD's PSP is an on-die coprocessor that runs before the x86 cores and holds them in reset until its own init completes, executing firmware that must carry a valid signature checked against an AMD public key baked into the boot ROM, and whose firmware images are versioned with an anti-rollback security version number — same "runs beneath and gates the hypervisor, and you can't get in without AMD's key" shape as Intel ME https://doc.coreboot.org/soc/amd/psp_integration.html https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf https://www.amd.com/content/dam/amd/en/documents/products/processors/technologies/amd-pro-technologies-security-white-paper.pdf https://libreboot.org/faq.html niveau 2/3 · plausible · vérifié le 2026-09-26 R49 FAQ Libreboot : PSP = cœur ARM + TrustZone sur la puce ; firmware signé ; sans lui les cœurs x86 restent en reset ; « ring -2 or ring -3 » ; pas d'équivalent à me_cleaner https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26
  67. R91 coreboot démarre des EPYC Turin récents avec openSIL (cartes

    EPYC en amont au 2026-10-29, master ab1a9352 : Gigabyte MZ33-AR1 Turin, carte de référence AMD Onyx Genoa ; ASRock Rack TURIND8UD en revue, https://review.coreboot.org/c/coreboot/+/95864) ; les blobs PSP publiés par AMD pour openSIL ne fonctionnent que sur des puces de pré-série, une puce de production demande ceux du paquet Turin PI https://review.coreboot.org/c/coreboot/+/88712 https://review.coreboot.org/c/coreboot/+/88710 https://github.com/openSIL/amd_firmwares/issues/1 niveau 1 · confirmé · vérifié le 2026-10-22 I26 Darth Maul cosplay at Star Wars Celebration Anaheim (2015), red saber lit; cropped to 16:9, red-darkened, stronger on the left under the text https://commons.wikimedia.org/wiki/File:SWCA_-_Darth_Maul_ image · licence : CC BY-SA 2.0 R112 Intel ME : à partir des PCH série 100, les microcontrôleurs passent d'ARCompact (ARC) à x86 : le cœur Minute IA, celui des Quark et Edison, « based on a rather old scalar Intel 486 microprocessor » avec le jeu d'instructions du Pentium ; l'OS est MINIX (avant : ThreadX). Tanenbaum confirme MINIX dans l'ME-11 mais dit l'avoir appris par la presse (même origine) https://positechglobal.com/en/research/analytics/disabling-intel-me-11-via-undocumented-mode/ https://www.cs.vu.nl/~ast/intel/ niveau 2 · confirmé · vérifié le 2026-10-26 28 J'ai regardé : un vrai EPYC Genoa R129 Machine AMD prêtée (EPYC Turin, Zen 5) : PSP verrouillé sur les deux sockets, valeurs identiques (sysfs ccp : fused_part=1, debug_lock_on=1, anti_rollback_status=1, tsme_status=0 ; dmesg : « SEV: memory encryption not enabled by BIOS ») ; TPM 2.0 présent ; PK enrôlée (user mode), Secure Boot désactivé, PK = clé de production du constructeur du serveur émise par sa propre AC de signature, pas une clé de test ; fwupd : « HSI:INVALID:chassis[rack-mount] » (pas de niveau sur un châssis rack ; HSI-1 passe, HSI-2 échoue sur Secure Boot désactivé et protection en écriture SPI) Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-29
  68. R92 La spécification UEFI permet d'enrôler sa propre clé de

    plateforme (PK) : sans PK, la plateforme est en « setup mode » et la PK peut être écrite ; ensuite seul le détenteur de la PK peut la changer https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html niveau 1 · confirmé · vérifié le 2026-10-22 R83 Sur ce serveur, Secure Boot n'a aucune clé enrôlée : firmware en Setup Mode, aucune variable PK, KEK, db ni dbx Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-21 R82 Sur ce serveur, le PSP est verrouillé : puce fusionnée contre la falsification, debug verrouillé, protection anti-rollback appliquée https://raw.githubusercontent.com/torvalds/linux/master/Documentation/ABI/testing/sysfs-driver-ccp niveau 1 · confirmé · vérifié le 2026-10-21 R86 L'hyperviseur installé sur ce serveur ne sait pas encore démarrer l'hôte en Secure Boot ; c'est en cours https://github.com/xcp-ng/xcp/issues/294 https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/ niveau 1 · confirmé · vérifié le 2026-10-22 R84 Ce serveur n'a pas de TPM, et fwupdmgr security lui donne HSI:0 (HSI-1 échoue sur le seul critère TPM 2.0) https://fwupd.github.io/hsi.html niveau 1 · confirmé · vérifié le 2026-10-21 R98 Échelle HSI de fwupd : HSI:0 « Insecure State » à HSI:5 « Secure Proven State » (HSI:5 pas encore atteignable : aucun test implémenté) ; cumulatif : « the default security level if no tests can be run or some tests in the next security level have failed » ; périmètre : « primarily designed for laptop and desktop hardware […] It is not expected that non-consumer hardware will publish an HSI number » https://fwupd.github.io/libfwupdplugin/hsi.html niveau 1 · confirmé · vérifié le 2026-10-24 R85 Ce serveur embarque au moins 10 images firmware distinctes Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-14 (relu 2026-10-21)
  69. R125 Windows 11 exige un TPM 2.0 https://www.microsoft.com/en-us/windows/windows-11-specifications niveau 1

    · confirmé · vérifié le 2026-10-28 29 Et chez Intel ? Mon NUC R87 Sur le NUC de l'orateur, le CSME (Intel ME) est présent en version 18.1, mode fabrication verrouillé, override verrouillé Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-22 R88 Boot Guard y est actif : l'empreinte de la clé publique du constructeur est gravée dans des fusibles à la fin de la fabrication, et seul un firmware signé par cette clé démarre https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/resources/key-usage-in-integrated-firmware-images.html niveau 1 · confirmé · vérifié le 2026-10-22 R89 Le NUC a un TPM 2.0 et des clés Secure Boot enrôlées : PK d'ASUS, KEK et db d'ASUS et de Microsoft Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-22 R90 fwupd donne HSI:3 au NUC (contre HSI:0 au serveur EPYC) https://fwupd.github.io/hsi.html niveau 1 · confirmé · vérifié le 2026-10-22 R98 Échelle HSI de fwupd : HSI:0 « Insecure State » à HSI:5 « Secure Proven State » (HSI:5 pas encore atteignable : aucun test implémenté) ; cumulatif : « the default security level if no tests can be run or some tests in the next security level have failed » ; périmètre : « primarily designed for laptop and desktop hardware […] It is not expected that non-consumer hardware will publish an HSI number » https://fwupd.github.io/libfwupdplugin/hsi.html niveau 1 · confirmé · vérifié le 2026-10-24
  70. I06 Carte mère du NUC de l'orateur, capot ouvert, rougie

    et assombrie ; la puce flash à côté de CN_SPI-S1 agrandie dans un cadre. Étiquettes de la carte Wi-Fi et du support, marquages des puces flash et EC, étiquette série/MAC floutés Photo ou dessin de l'auteur, original non publié image · licence : © Bruno Verachten, publiée avec le deck R101 Sur le NUC, une seule puce flash de 32 Mo : environ 9 Mo pour l'Intel ME, 16 Mo pour le BIOS ; la zone BIOS est verrouillée en écriture, même pour l'OS Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-23 R99 Sur ces processeurs, la puce flash SPI est reliée directement au processeur, et la région CSME (Intel ME) est obligatoire dans cette flash, à côté de celle du BIOS https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/core-ultra-200h-and-200u-series-processors-datasheet-volume-1-of-2/spi 0-for-flash/ niveau 1 · confirmé · vérifié le 2026-10-23 R100 Le CSME est un petit processeur x86 à part, avec sa mémoire, isolé des cœurs que vous utilisez : un CPU dans votre CPU https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/core-ultra-200h-and-200u-series-processors-datasheet-volume-1-of-2/inte l-converged-security-and-management-engine-intel-csme/ niveau 1 · confirmé · vérifié le 2026-10-23 30 Qui est root, vraiment ? R114 Anneaux de privilège x86 : le processeur reconnaît 4 niveaux, numérotés de 0 à 3, « the greater numbers mean lesser privileges » ; Intel les dessine en anneaux, le noyau au centre (figure 5-3) ; un accès vers un niveau plus privilégié lève une #GP. Un hyperviseur (VMM) tourne en « VMX root operation », l'invité en « VMX non-root », et « guest software can run at the privilege level for which it was originally designed » : le noyau invité reste en CPL 0, d'où le « ring -1 » familier, qui n'est pas un terme Intel https://cdrdv2-public.intel.com/671447/325384-sdm-vol-3abcd.pdf niveau 1 · confirmé · vérifié le 2026-10-27
  71. 31 Qui est root, vraiment ? R49 FAQ Libreboot :

    PSP = cœur ARM + TrustZone sur la puce ; firmware signé ; sans lui les cœurs x86 restent en reset ; « ring -2 or ring -3 » ; pas d'équivalent à me_cleaner https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26 R100 Le CSME est un petit processeur x86 à part, avec sa mémoire, isolé des cœurs que vous utilisez : un CPU dans votre CPU https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/core-ultra-200h-and-200u-series-processors-datasheet-volume-1-of-2/inte l-converged-security-and-management-engine-intel-csme/ niveau 1 · confirmé · vérifié le 2026-10-23 L07 AMD's PSP is an on-die coprocessor that runs before the x86 cores and holds them in reset until its own init completes, executing firmware that must carry a valid signature checked against an AMD public key baked into the boot ROM, and whose firmware images are versioned with an anti-rollback security version number — same "runs beneath and gates the hypervisor, and you can't get in without AMD's key" shape as Intel ME https://doc.coreboot.org/soc/amd/psp_integration.html https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf https://www.amd.com/content/dam/amd/en/documents/products/processors/technologies/amd-pro-technologies-security-white-paper.pdf https://libreboot.org/faq.html niveau 2/3 · plausible · vérifié le 2026-09-26 32 Il y a un CPU dans votre CPU. L05 Intel ME / AMD PSP: closed, cryptographically-signed firmware on a coprocessor with more privilege than the hypervisor; cannot be removed (post-Nehalem systems force-shutdown after ~30 min without valid ME firmware); Intel's own 2017 advisory (INTEL-SA-00086) confirms remotely-exploitable and local-privilege-escalation flaws in ME/TXE/SPS across 1st-8th gen Intel Core and Xeon E3 v5/v6 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html https://www.cisa.gov/news-events/alerts/2017/11/21/intel-firmware-vulnerability niveau 1 · confirmé · vérifié le 2026-09-26
  72. L07 AMD's PSP is an on-die coprocessor that runs before

    the x86 cores and holds them in reset until its own init completes, executing firmware that must carry a valid signature checked against an AMD public key baked into the boot ROM, and whose firmware images are versioned with an anti-rollback security version number — same "runs beneath and gates the hypervisor, and you can't get in without AMD's key" shape as Intel ME https://doc.coreboot.org/soc/amd/psp_integration.html https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf https://www.amd.com/content/dam/amd/en/documents/products/processors/technologies/amd-pro-technologies-security-white-paper.pdf https://libreboot.org/faq.html niveau 2/3 · plausible · vérifié le 2026-09-26 R49 FAQ Libreboot : PSP = cœur ARM + TrustZone sur la puce ; firmware signé ; sans lui les cœurs x86 restent en reset ; « ring -2 or ring -3 » ; pas d'équivalent à me_cleaner https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26 I04 Pentium II die shot, red-darkened, with a magnified piece of the same die framed https://commons.wikimedia.org/wiki/File:Intel-pentium-ii-dixon-die-shot-high-resolution-stitched.jpg image · licence : Public domain 33 « Mais il y a mecleaner ! » R48 me_cleaner retire des modules du firmware ME et positionne le bit AltMeDisable https://doc.coreboot.org/northbridge/intel/sandybridge/me_cleaner.html niveau 1 · confirmé · vérifié le 2026-09-26 R46 Dasharo désactive l'Intel ME via le bit HAP : le firmware ME reste présent en flash, arrêté (pas retiré) https://docs.dasharo.com/osf-trivia-list/me/ niveau 1 · confirmé · vérifié le 2026-09-26
  73. L06 Independent researchers (Positive Technologies: Dmitry Sklyarov, Mark Ermolov, Maxim

    Goryachy) found in August 2017 that Intel ME 11 can be halted via an undocumented "HAP" (High Assurance Platform) bit — Intel later confirmed the field exists "at the request of equipment manufacturers in support of their customer's evaluation of the US government's 'High Assurance Platform' program." Evidence the ME is not just closed but was never meant to be user-inspectable: the owner needed a researcher-found undocumented field to even halt it, and Intel's own reason for it existing was a government customer, not the end user https://positechglobal.com/en/research/analytics/disabling-intel-me-11-via-undocumented-mode/ https://soylentnews.org/article.pl?sid=17/09/01/0229244 niveau 4 · plausible · vérifié le 2026-09-26 R49 FAQ Libreboot : PSP = cœur ARM + TrustZone sur la puce ; firmware signé ; sans lui les cœurs x86 restent en reset ; « ring -2 or ring -3 » ; pas d'équivalent à me_cleaner https://libreboot.org/faq.html niveau 3 · plausible · vérifié le 2026-09-26 35 Le fond de la grotte (x86) R50 ISA x86 propriétaire : personne d'autre qu'Intel, AMD et une poignée de licenciés historiques (VIA/Zhaoxin) ne peut légalement fabriquer une puce x86 — pas une question de documentation manquante mais de brevets croisés fermés à tout nouvel entrant https://www.sec.gov/Archives/edgar/data/2488/000119312509236705/dex102.htm https://cdrdv2-public.intel.com/671110/325383-sdm-vol-2abcd.pdf niveau 1 · confirmé · vérifié le 2026-09-26 R130 ISA POWER ouverte : depuis le 2019-08-20, n'importe qui peut implémenter le Power ISA sans royalties, avec une licence de brevets pour les puces conformes https://openpowerfoundation.org/blog/final-draft-of-the-power-isa-eula-released/ niveau 1 · confirmé · vérifié le 2026-10-29
  74. R51 Raptor : sources firmware de plateforme publiées (hostboot, skiboot,

    SBE, OCC, OpenBMC) ; dépôts inactifs depuis des années https://git.raptorcs.com/git/ https://wiki.raptorcs.com/wiki/Category:Documentation niveau 1 · confirmé · vérifié le 2026-09-26 (re-vérif d'accessibilité) 37 Étage bonus : le disque. « Chiffré », vraiment ? L08 SSD controllers run their own closed ARM-core firmware below the OS, and that firmware is itself an unauditable trust boundary: a 2018 peerreviewed study (Meijer & van Gastel, Radboud University, IEEE S&P) found firmware/debug-interface flaws in several Crucial and Samsung selfencrypting SSDs (CVE-2018-12037, CVE-2018-12038) that let an attacker recover data without the user's password — the "encrypted" guarantee lived entirely in unauditable controller firmware https://www.ieee-security.org/TC/SP2019/papers/310.pdf niveau 1 · confirmé · vérifié le 2026-09-26 R126 L'autorité de certification eMudhra avait huit certificats intermédiaires à clés privées faibles, dont six certificats TLS reconnus par les quatre grands programmes racine ; la clé privée de l'intermédiaire EM OV TLS CA - G3C vaut 4 ; eMudhra attribue l'incident à une erreur de script https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 https://emudhra.com/en/post/certificate-security-incident https://gist.github.com/Fluepke/9a103c7f990c3cc2fb5002f7476f2f48 niveau 1 · confirmé · vérifié le 2026-10-28
  75. 38 La ligne bouge. Dans les deux sens. R68 FCC,

    2016-08-01 : accord (Consent Decree) avec TP-Link, 200 000 $ ; les mises à jour de TP-Link pour se conformer aux règles U-NII « precluded customer installation of third-party software, including open-source software » ; TP-Link s'engage à travailler avec la communauté open source et les fabricants de puces pour permettre les firmwares tiers ; les règles « do not prohibit third-party device software (including open-source software) » https://docs.fcc.gov/public/attachments/DOC-340564A1.pdf https://docs.fcc.gov/public/attachments/DA-16-850A1.pdf niveau 1 · confirmé · vérifié le 2026-10-24 R108 Après l'accord : des routeurs TP-Link vendus aux États-Unis acceptent OpenWrt directement depuis la page de mise à jour de TP-Link https://openwrt.org/toh/tp-link/archer_a7_v5 https://git.openwrt.org/30915e5a70ccb3b1f5f562a0f45ef49edf81194d niveau 1 · plausible · vérifié le 2026-10-24 41 1. Inventorier R56 fwupd : démon de mise à jour firmware, LGPL-2.1 ; fwupdmgr get-devices https://github.com/fwupd/fwupd niveau 1 · confirmé · vérifié le 2026-09-27 42 2. Mesurer R84 Ce serveur n'a pas de TPM, et fwupdmgr security lui donne HSI:0 (HSI-1 échoue sur le seul critère TPM 2.0) https://fwupd.github.io/hsi.html niveau 1 · confirmé · vérifié le 2026-10-21
  76. R57 tpm2-tools fournit tpm2_eventlog ; event log lisible via /sys/kernel/security/tpm0/binary_bios_measurements

    https://github.com/tpm2-software/tpm2-tools https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/common.c niveau 1 · confirmé · vérifié le 2026-09-27 44 Premier démarrage R56 fwupd : démon de mise à jour firmware, LGPL-2.1 ; fwupdmgr get-devices https://github.com/fwupd/fwupd niveau 1 · confirmé · vérifié le 2026-09-27 R57 tpm2-tools fournit tpm2_eventlog ; event log lisible via /sys/kernel/security/tpm0/binary_bios_measurements https://github.com/tpm2-software/tpm2-tools https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/common.c niveau 1 · confirmé · vérifié le 2026-09-27 R74 Sur cet OptiPlex, le premier événement de l'event log est « Boot Guard Measured S-CRTM » : le premier bloc de firmware est mesuré par Intel Boot Guard avant tout code ouvert Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-09-27 R115 Intel AMT : « Platforms equipped with Intel AMT can be managed remotely, regardless of its power state or if it has a functioning OS or not » ; « The Intel® Converged Security and Management Engine (Intel® CSME) powers the Intel AMT system » ; avant usage, il « must be prepared or provisioned » https://www.intel.com/content/www/us/en/developer/articles/guide/getting-started-with-active-management-technology.html niveau 1 · confirmé · vérifié le 2026-10-27
  77. 45 Second démarrage R75 Changer l'ordre de boot change une

    entrée de l'event log (BootOrder) et en déplace deux (Boot0001, Boot0002, mesurées dans l'ordre de BootOrder) ; PCR1 change. Redémarrage témoin sans changement : 0 différence, PCR identiques Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-09-27 R76 PCR10 change aussi, parce que sa seule entrée ici est boot_aggregate d'IMA, calculée sur les PCR du firmware https://github.com/torvalds/linux/blob/fd179f8a05be3ccae366b9b96e176b51fbe54aab/security/integrity/ima/ima_crypto.c#L455-L470 niveau 1 · confirmé · vérifié le 2026-09-27 46 3. Attester R58 Keylime : projet CNCF (niveau Sandbox, accepté le 2020-09-22), Apache-2.0, attestation à distance au démarrage et intégrité à l'exécution sur racine de confiance matérielle (TPM), né au MIT Lincoln Laboratory https://github.com/keylime/keylime https://www.cncf.io/projects/keylime/ https://keylime.dev/ niveau 1 · confirmé · vérifié le 2026-10-28 R81 Keylime : en cas d'échec d'attestation, le vérificateur envoie un message de révocation ; ce que le nœud fait ensuite dépend de l'intégration (actions de révocation configurées) https://keylime.readthedocs.io/en/latest/design/overview.html niveau 1 · confirmé · vérifié le 2026-10-21
  78. 47 4. Épingler R56 fwupd : démon de mise à

    jour firmware, LGPL-2.1 ; fwupdmgr get-devices https://github.com/fwupd/fwupd niveau 1 · confirmé · vérifié le 2026-09-27 R59 LVFS : service de distribution de firmwares utilisé par fwupd https://fwupd.org/lvfs/ niveau 1 · confirmé · vérifié le 2026-09-26 48 5. Isoler L03 BMC (out-of-band management): vendor BMCs (Dell iDRAC, HPE iLO, Lenovo XClarity, Fujitsu iRMC, Supermicro) are closed; OpenBMC is the open-source alternative (started 2014-15, Facebook/IBM/Rackspace, now backed by Microsoft/Intel/IBM/Google/Facebook) https://github.com/openbmc/openbmc https://lwn.net/Articles/683583/ https://queue.acm.org/detail.cfm?id=3378404 niveau 1 · confirmé · vérifié le 2026-09-26 R01 Ruter (Oslo) tested a new Yutong e-bus and a 3-year-old VDL bus in an isolated environment inside a mountain (« inne i et fjell »); the Yutong's OTA channel gives the manufacturer digital access to the battery/power-supply control system via a Romanian SIM, so in theory the bus could be stopped or disabled remotely; the VDL bus has no OTA capability https://ruter.no/nyheter/ruter-med-omfattende-sikkerhetstest-av-elektriske-busser niveau 1 · confirmé · vérifié le 2026-09-26
  79. 49 Et si vos serveurs sont chez quelqu'un d'autre ?

    R93 Google Shielded VM : le vTPM fait le measured boot de la VM ; integrity monitoring compare les mesures à une référence https://docs.cloud.google.com/compute/shielded-vm/docs/shielded-vm niveau 1 · confirmé · vérifié le 2026-10-22 R94 AWS NitroTPM : TPM 2.0 virtuel, measured boot, attestation à distance https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitrotpm.html niveau 1 · confirmé · vérifié le 2026-10-22 R95 Azure Trusted Launch : vTPM TPM 2.0, mesure de la chaîne de démarrage de la VM, attestation à distance https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch niveau 1 · confirmé · vérifié le 2026-10-22 R96 Nœuds Kubernetes managés confidentiels : Confidential GKE Nodes, chiffrement mémoire matériel, AMD SEV, SEV-SNP, Intel TDX https://docs.cloud.google.com/kubernetes-engine/docs/how-to/confidential-gke-nodes niveau 1 · confirmé · vérifié le 2026-10-22 R97 Chez AMD, le rapport d'attestation SEV-SNP vient du firmware SEV, qui tourne dans l'AMD Secure Processor, c'est-à-dire le PSP https://docs.kernel.org/virt/coco/sev-guest.html niveau 1 · confirmé · vérifié le 2026-10-22 R116 Confidential VM : la mémoire privée de la VM est chiffrée contre l'hôte, pas seulement « par le matériel » https://docs.kernel.org/arch/x86/amd-memory-encryption.html https://docs.kernel.org/arch/x86/tdx.html niveau 1 · confirmé · vérifié le 2026-10-27
  80. 52 L10 🛗 Même ascenseur, autre immeuble : RISC-V RISC-V

    pairs an open ISA with OpenSBI, an open-source supervisor/boot firmware — the first time the firmware layer beneath the OS is itself open source https://github.com/riscv-software-src/opensbi niveau 1 · confirmé · vérifié le 2026-09-26 R60 Spécification ISA RISC-V publique https://docs.riscv.org/reference/isa/v20260120/unpriv/unpriv-index.html https://docs.riscv.org/reference/isa/v20260120/priv/priv-index.html niveau 1 · confirmé · vérifié le 2026-09-26 R117 RISC-V : la spécification de démarrage des serveurs impose UEFI et ACPI https://docs.riscv.org/reference/brs/v1.0/index.html niveau 1 · confirmé · vérifié le 2026-10-27 R118 Un serveur RISC-V conforme doit suivre la recette BRS-I (UEFI) https://github.com/riscv-non-isa/riscv-server-platform niveau 1 · confirmé · vérifié le 2026-10-27 R119 Un serveur rack RISC-V a un BMC https://en.sophgo.com/sophon-u/product/introduce/sra3-40.html niveau 1 · confirmé en partie (reste : non vérifié) · vérifié le 2026-10-27 R120 Deuxième exemple : le SpacemiT V100 annonce un BMC https://spacemit.com/news/2c9c8082a1770faf01a17ccdbbce0000 niveau 4 · plausible · vérifié le 2026-10-27
  81. 53 Et sur RISC-V ? Ma Banana Pi F3 R103

    Sur la BPI-F3, le premier chargeur (FSBL), l'initialisation de la mémoire et U-Boot sont du C sous GPL, publié par SpacemiT, et c'est exactement le commit que la distribution déclare avoir compilé https://gitee.com/bianbu-linux/uboot-2022.10.git niveau 1 · confirmé en partie (reste : non vérifié) · vérifié le 2026-10-23 R104 OpenSBI, sur cette carte, est compilé depuis le fork d'un contributeur, pas depuis le projet amont https://github.com/pyavitz/spacemit-opensbi.git niveau 1 · confirmé · vérifié le 2026-10-23 R105 Un deuxième cœur, RISC-V 32 bits, exécute esos.elf (RT-Thread), démarré par Linux ; la distribution ne le compile pas, elle copie un binaire déposé en juin 2024 ; la source est pourtant publiée par SpacemiT sous Apache-2.0 https://gitee.com/spacemit-buildroot/esos niveau 1 · confirmé en partie (reste : non vérifié) · vérifié le 2026-10-23 R106 La SpacemiT K1 n'a pas l'extension hyperviseur (H) Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-23 54 Une ISA ouverte n'est pas un cœur ouvert R61 SiFive P550 vendu comme IP de processeur sous licence https://www.sifive.com/cores/performance-p550 niveau 4 · plausible · vérifié le 2026-09-21 (via kb) R62 CVA6 : RTL publié, démarre Linux ; flux FPGA de référence Vivado/Xilinx ; extension H dans le RTL depuis la 5.1.0 (2024-07-11) https://github.com/openhwfoundation/cva6/releases/tag/v5.1.0 niveau 1 · confirmé · vérifié le 2026-10-25
  82. 55 16 cœurs. Enfin… 8. R63 SpacemiT K3 : H,

    AIA, IOMMU annoncés https://cdn.sipeed.com/public/k3/Introduction%20to%20K3%20Series%20Chips.pdf niveau 4 · plausible · vérifié le via kb R64 K3 : les 8 cœurs X100 portent l'extension « h » et aucun nœud IOMMU n'est décrit ; les 8 cœurs A100 n'ont pas « h » (8 sur 16) https://github.com/spacemit-com/linux/blob/cee9395acd8043be0644b25c34bfa86623f2b935/arch/riscv/boot/dts/spacemit/k3.dtsi https://github.com/sanderjo/SpacemiT-K3-X100-A100/blob/7a75d9d634ff6cd6602ba6c296bbe821bf188e10/proc-cpuinfo.md https://matrix.to/#/!vsRtsMjirGWgqeWdfv:matrix.org/$B3SZ5FLx_JZJ0ERZ8OiDRyOJDBVHAzmbEPZT95mTJUo?via=vates.tech&via=matrix.org&via=tetaneutral.net niveau 1 · confirmé en partie (reste : plausible) · vérifié le 2026-10-24 56 Xen sur RISC-V, en amont R65 Port RISC-V de Xen en amont : code commun, headers asm-generic https://xcp-ng.org/blog/2024/09/23/advancing-xen-on-risc-v-key-updates/ niveau 4 · plausible · vérifié le — R73 Docker Engine v29.8.1 construit pour riscv64 par l'auteur (dépôt personnel, builds communautaires, pas une version officielle de Docker) ; publié le 2026-09-20, quelques jours après la release amont moby docker-v29.8.1 du 2026-09-15 https://github.com/gounthar/docker-for-riscv64/releases/tag/v29.8.1-riscv64 https://github.com/moby/moby/releases/tag/docker-v29.8.1 niveau 1 · confirmé · vérifié le 2026-09-26 R121 Xen Orchestra gère un hôte XCP-ng RISC-V, et Doom tourne dans une VM — émulé, sous QEMU sur x86 https://www.linkedin.com/posts/baptiste-le-duc_xen-riscv-xcpng-activity-7519343442448183296-CWbR niveau 1 · confirmé · vérifié le 2026-10-27
  83. 57 Ce qui manque encore R107 SpacemiT V100 : puce

    serveur, 46 cœurs, RVA23, Hypervisor 1.0, AIA, virtualisation des périphériques par IOMMU ; « première puce entièrement conforme aux spécifications serveur RISC-V » ; annoncée, pas de date de livraison https://www.spacemit.com/products/keystone/v100 niveau 4 · plausible · vérifié le 2026-10-24 R66 Xen : le cadre d'assignation IOMMU basé sur device tree est générique (pas spécifique à une architecture), donc disponible pour RISC-V qui est déjà basé sur device tree ; mais aucun pilote IOMMU matériel RISC-V n'existe, et le code p2m RISC-V lui-même dit ne pas être prêt pour l'IOMMU https://github.com/xen-project/xen/blob/master/xen/drivers/passthrough/device_tree.c https://github.com/xen-project/xen/blob/master/xen/drivers/passthrough/Kconfig https://github.com/xen-project/xen/blob/master/xen/arch/riscv/p2m.c niveau 1 · confirmé · vérifié le 2026-09-26, re-vérifié 2026-10-21 sur staging = master `7e020a4` (2026-10-15) : toujours aucun pilote IOMMU RISC-V. Affirmation au présent sur du code vivant : re-vérifier la veille du talk R127 Openchip (Barcelone) a annoncé le 2026-07-30 la BER10, un processeur RISC-V 64 bits capable de faire tourner Linux, à quatre cœurs, en silicium ; une fois l'OS démarré, leur premier réflexe a été de lancer Doom ; le PDG dit qu'elle repose sur de l'IP déjà éprouvée et qu'il ne peut pas tout détailler https://openchip.com/openchip-unveils-ber10-europes-new-sovereign-chip-is-here/ https://riscv.org/blog/v-questions-with-openchips-cesc-guim-and-marc-fernandez/ niveau 4 · plausible · vérifié le 2026-10-28 58 Des switches à l'abandon R69 Christopher Wright (@salvagedsilicon) : un OS réseau open source pour des switches d'entreprise abandonnés par leurs constructeurs ; séquence d'init des puces et formats des tables retrouvés par rétro-conception à l'établi, sans SDK Broadcom sous licence ; commutation dans le silicium, pas par le CPU, d'après son auteur ; « Every platform I add starts with buying the switch. They're cheap on eBay » https://github.com/wrightca1 niveau 1 · confirmé · vérifié le 2026-09-26 ⚠️ revérifier la semaine du talk
  84. R70 NOSaic, successeur d'EdgeNOS (org créée le 2026-08-26, Apache-2.0). Colonne

    de statut du README à 49d0ffa (2026-10-12) : Arista 7050SX272Q, Arista 7050TX-64 et Edgecore AS5610-52X experimental ; Cisco Nexus 3172TQ bringup (à 60d3fd0, le 7050TX-64 était encore en bringup) ; Edgecore AS4610-54T planned. Règle de l'auteur : « Status is what has been demonstrated on that board, not what is intended » ; « Nothing is production ». Note : la prose du README dit « Four switches run NOSaic », le tableau en met trois au-delà de bringup (le Nexus 3172TQ démarre par le réseau, toujours bringup) ; le deck suit le tableau. Dell (S6000-ON, planned) n'existe que dans le fork wrightca1/nosaicswitch à 732d176, pas en amont https://github.com/Salvaged-silicon/nosaic-switch/blob/49d0ffae383438955c6c8f2d6204eb18bbb0238f/README.md niveau 1 · confirmé · vérifié le 2026-10-29 R71 Rétro-conception de l'Edgecore AS5610-52X (BCM56846) : cartes de registres, formats de tables, protocole S-channel, sans la documentation confidentielle de Broadcom ⚠️ https://github.com/wrightca1/edgecore-5610-reverse-engineering niveau 1 · confirmé · vérifié le 2026-09-26 revérifier R128 Christopher Wright corrige publiquement sa propre analyse d'un Cisco Nexus 9396PX (une seule puce de commutation, pas deux) et, d'après lui, l'encapsulation VXLAN est présente mais désactivée dans NX-OS https://www.linkedin.com/posts/christopher-wright-switches_cisco-nexus-9396px-i-physically-opened-it-share-7520538811219591168-Hrph/ niveau 1 · confirmé en partie (reste : plausible) · vérifié le 2026-10-29 60 Et le bus ? R04 Danish operator Movia commissioned EY to independently risk-assess cybersecurity across 7+ EV bus/vehicle manufacturers (incl. Chinese ones) serving its routes; EY found no basis to consider Chinese buses less cybersecure than other manufacturers, and in fact the Dutch manufacturer (VDL) scored the lowest documented cybersecurity maturity of the group (10% governance, 0% risk analysis) against Yutong's near-complete scores (100%/95%/100%/100%/100%/93%) https://www.moviatrafik.dk/media/3topzxnw/risk-assessment-of-cybersecurity-for-ev-bus-and-ev-vehicles____final-2296728_-1.pdf https://via.ritzau.dk/pressemeddelelse/15161742/elbusser-overholder-lovregulering-af-cybersikkerhed niveau 1 · confirmé · vérifié le 2026-09-26
  85. R85 Ce serveur embarque au moins 10 images firmware distinctes

    Mesure ou note de l'auteur, non publiée niveau 1 · confirmé · vérifié le 2026-10-14 (relu 2026-10-21) I05 Croix-Rousse tunnel (Lyon), bus-lane entrance of the soft-modes tube in daylight, BUS painted on the road (lightened) https://commons.wikimedia.org/wiki/File:Lyon_1er_-_Tunnel_de_la_Croix-Rousse,_entr%C3%A9e_du_tube_modes_doux,_c%C3%B4t%C3%A9_Rh%C3%B4ne.jpg image · licence : CC0