Bonsoir,
Il y a bien longtemps que je n'ai écris de journal. Il faut dire que l'année 2019 a été un tsunami de mon cote suite à l'acquisition de ma société par un groupe américain, un déménagement outre atlantique et un départ de celui-ci pour rejoindre HPE à Houston, où je pilote la stratégie Open Platform. Me voila "influenceur" (plutot que chef on va dire) chez un constructeur, et de retour à mes sources (j'avais quitté HPE pour créer ma structure en 2006).
Je ne suis pas là pour faire de la pub pour HPE, meme si indirectement je vais vous parler de mes priorités, et j'aimerai avoir l'opportunité d'avoir un échange avec vous sur ce que je fais. Je n'ai pas abandonné mes développements FreeCAD (ils seront le sujet d'un prochain journal leur étant dédié), et l'actualité sur ce sujet est d'ailleurs très riche suite à ma rencontre (physique!) avec d'autres développeurs lors du dernier Fosdem.
Certains d'entres vous le savent je suis un des co-createurs de linuxboot un environnement qui permet de s'affranchir au maximum de codes propriétaires au niveau des BIOS des serveurs. J'ai travaillé aussi sur des approches équivalentes au niveau des BMC (les chips de remote management de ces memes serveurs) au travers de projets comme OpenBMC et u-bmc. Ces projets ont été présentes plusieurs fois lors de conférences internationales comme OCP et/ou Fosdem (Facebook y a fait un très bon talk cette année sur la manière dont ils testent les dits microcodes).
En arrivant chez HPE, il m'était évident que cette approche allait créer un choc culturel. Il faut dire que l'engineering local développe ses propres BIOS avec succès depuis plus de 25 ans sur les systèmes ProLiant, et arriver avec une approche ou on casse tout, au profit du kernel linux, il faut avouer que je me suis dit qu'en tant que Francais au Texas, il allait falloir etre subtil et prudent.
Apres quelques mois, d'engueulades positives et bbq (on résout pas mal de choses autours d'un bbq ici), on a réussi à avoir des Proliant qui démarrent sous OpenBMC (Gen10/skylake) ainsi que linuxboot. Ils ont été présentés d'ailleurs pour l'un d'entre eux cette année à Bruxelles au Fosdem (second choc culturel d'ailleurs). La difficulté technique repose principalement sur la mise en oeuvre des mécanismes de protection (légitime) des microcodes depuis quelques années (Silicon Root of Trust, et Intel Bootguard en sont quelques exemples). Comment concilier liberté de choix et mécanisme de protection ?
Apres cette étape de tests au travers de PoC (Proof of Concept), nous sommes entrés dans la phase suivante de pré-industrialisation. Ils nous restent évidemment beaucoup de travail, tests et validations. Mais vous allez pouvoir y participer, enfin j'espère. Nous sommes en train d'assembler des prototypes de DL360Gen10, que nous allons proposer à quelques uns de nos gros et petits clients, qui souhaitent s'impliquer dans cette aventure. Si vous en faites parties, faites moi signe !
Etant un fervent défenseur des travaux communautaires, et de la nécessité d'offrir la possibilité à tout le monde de tester les microcodes libres, j'ai créée un petit projet dénommé OSFCI (Open Source Firmware Continuous Integration) disponible sur github, et au travers d'une plateforme en ligne qui permet de tester a distance un serveur Proliant qui fonctionne sur OpenBMC, et linuxboot. Evidemment il reste beaucoup de travail, mais celui-ci peut se faire de manière collaborative et a bien entendu démarré au travers de communautés des microcodes libres.
Vous pouvez acceder a la plateforme fonctionnelle sur https://osfci.tech. Nous l'utilisons pour valider nos propres développements et cela fonctionne plutot bien durant cette pandémie qui nous touche tous. L'idée étant de recompiler une image openbmc et/ou linuxboot en local, de la télécharger sur un FPGA connecté a un ProLiant qui va émuler des Flash SPI, et de controler a distance l'alimentation électrique du serveur. Une fois allumé, les consoles des différents microcodes sont accessibles. Une image de demo est disponible par défaut.
Nous travaillons sur une API qui permettra de faire tout cela en mode automatique, permettant ainsi de valider chaque assemblage de microcode à la volée.
Les microcodes propriétaires ne vont pas disparaitre, mais les logiciels libres arrivent à se créer une place dans ce domaine et j'espère que chacun pourra ainsi choisir sa stratégie de sécurité au travers d'options soient totalement propriétaires soit totalement auditables, modifiables et libres.
N'hésitez pas à me fournir votre retour sur cette approche qui me tient sincèrement à coeur.
vejmarie
# Congrats
Posté par LoloB . Évalué à 6.
La boîte où je travaille a plutôt tendance à acheter des Lenovo plutôt que des HP.
Mais en tout cas, bravo de driver cette stratégie et d'arriver petit à petit à mettre en œuvre du logiciel libre à ce (bas) niveau chez un grand constructeur.
[^] # Re: Congrats
Posté par vejmarie (site web personnel) . Évalué à 10.
Merci pour votre soutien. La mise en oeuvre d'une telle strategie a l'echelle d'un groupe comme HPE est en effet un challenge a part entiere, mais aussi une aventure humaine tres interessante a vivre, meme si on passe par des hauts et des bas ! Peut-etre qu'un jour vous reviendrez sur des machines plus "transparentes" et/ou pionnieres.
[^] # Re: Congrats
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Un grand bravo pour ce parcours professionnel si riche.
Je me souviens de tes premières tentatives pour que HP puisse fournir des PC sans Windows. HP l'avait permis sur des machines en fin de commercialisation et à des prix élevés. On appelle ça un sabotage.
Tes serveurs dans l'huile et sur les toits m'ont aussi beaucoup intrigué.
En 2010, j'avais acheté un Quietty, une petite machine étonnante qui gérait et surveillait ma maison d'Arcachon. C'était une machine complètement statique avec laquelle j'ai eu plus de 18 mois de fonctionnement entre 2 boot. J'en parle au passé car elle est tombée en panne au début du confinement. Je vais sans doute la remplacer par un raspberry.
Il me tarde d'avoir des machines qui démarrent en moins d'une seconde sur un SSD sans passer par in BIOS UEFI et sans partition FAT32 sur un support GPT.
C'est un peu une lettre au père Noël que je fais là, mais je pense que c'est en ton pouvoir.
[^] # Re: Congrats
Posté par Megagolgoth . Évalué à 1.
1- "Congrats !", déjà ;)
2- Pourquoi HPE vous a embauché sur ça? Quel est le but?
En effet vous indiquez que l' "engineering local développe ses propres BIOS avec succès depuis plus de 25 ans sur les systèmes ProLiant".
[^] # Re: Congrats
Posté par Megagolgoth . Évalué à 2.
En fait globalement la question pourrait être aussi : Pourquoi HPE veut/essaye d'avoir Linuxboot/OpenBMC sur Proliant ?
[^] # Re: Congrats
Posté par lym . Évalué à 0.
Pour avoir un avantage concurrentiel avec des machines qui démarrent beaucoup plus vite, peut-être!
En arriver à passer plus de temps dans le BIOS qu'au démarrage d'un OS complet, c'est quand même un peu le miracle de l'UEFI: 3 phases étanches (SEC, et surtout PEI/DXE), un agglomérat du RC/MRC Intel, EDK2, auxquelles on ajoute le propre code du fournisseur de BIOS (configuration, son code legacy, son système de build mal fichu qui colle plus ou moins bien les morceaux).
On a donc bien souvent des choses écrites quasiment à l'identique dans ces 3 phases et pour les 3 origines possibles (avec de bonnes raisons à cela, le fournisseur de BIOS pouvant utiliser une chaîne de compil microsoft, Intel la sienne et EDK2 GCC).
Forcément, ce n'est pas très efficient. Surtout quand on charge cela (et tous les firmwares obscurs dont Intel raffole) d'une flash SPI.
J'espère de tout coeur que vous réussirez, revenu sur Intel en me bouchant le nez (avec un niveau de support très bas sur ces sujets) après plus de 2 décennies sur le PowerPC dans l'industrie télécoms.
Maintenant, sur des machines destinées à faire tourner Linux, il serait bon de commencer à faire du lourd passé Intel table rase. Le PowerPC crève de la politique d'IBM hélas, mais RiscV progresse…
# Merci !
Posté par oau . Évalué à 4.
Merci pour ce que vous faites, j'ai travaillé pendant longtemps sur du matériel HP avec des DL et j'ai toujours beaucoup aimé leur robustesse, leur stabilité et leur ouverture vers linux. Si en plus maintenant on va avoir du logiciel libre dedans c'est fantastique.
[^] # Re: Merci !
Posté par Sytoka Modon (site web personnel) . Évalué à 5. Dernière modification le 13 mai 2020 à 09:08.
En parallèle des serveurs, cela pourrait être intéressant de le faire aussi sur les commutateurs dont l'espérance de vie est plus grande que les serveurs. Avoir un commutateur / routeur libre serait top pour une maintenance très long terme.
[^] # Re: Merci !
Posté par claudex . Évalué à 5.
Tu parle de https://www.openswitch.net/ ou de Cumulus (récemment racheté par nVidia) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci !
Posté par Quinane . Évalué à 3.
Ou Interface Masters qui propose des switchs OpenSwitch et OCP.
[^] # Re: Merci !
Posté par Quinane . Évalué à 3.
Je rajoute : cela va-t-il dégager cette s…. d'IME ?
Purism propose un serveur Coreboot, sans IME : https://puri.sm/products/librem-server/
[^] # Re: Merci !
Posté par claudex . Évalué à 5.
Il existe déjà des switch avec des ARM ou des PPC, donc je ne vois pas le problème à dégager l'IME.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci !
Posté par Anonyme . Évalué à 5. Dernière modification le 13 mai 2020 à 15:40.
Oui comme dit dans le nourjal, il y a OpenBMC et ça tourne sur ARM. C'est ce genre de SoC qui est installé sur une partie des cartes mères OpenPower.
[^] # Re: Merci !
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je pensais à la couche firmware des commutateurs, pas forcément à la couche logicielle par dessus. Je n'ai pas testé Cumulus avec avec lui, tu charges 100% des firmwares de la boiboite ?
[^] # Re: Merci !
Posté par claudex . Évalué à 3.
Oui, tu charge un gros firmware proprio de chez broadcom pour la puce du switch. Je ne sais pas ce qu'il en est pour les asic Mellanox.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci !
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je sais qu'on peut changer d'OS sur les commutateurs DELL. Est-ce que quelqu'un a déjà essayé ?
[^] # Re: Merci !
Posté par claudex . Évalué à 5.
Ce n'est pas possible pour tous (je crois que c'est que la gamme Open Network (ON))
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Merci !
Posté par vejmarie (site web personnel) . Évalué à 5.
Le projet SONiC travaille sur ce type de sujets, il est plus dynamique que FBOSS, et supporte par de plus en plus de hardware.
# pas là pour faire de la pub pour HPE
Posté par abriotde . Évalué à 2.
# HP-ILO
Posté par Benjamin Henrion (site web personnel) . Évalué à 3.
Peut-être un jour les managers de chez HP se réveilleront.
J'ai dû un jour redémarrer un serveur critique, la console HP-ILO était buggée, impossible de faire un power cycle de la machine.
C'est quand même bien HP, la fonctionnalité numero 1 de leur ILO ne fonctionnait pas!
Ou peut-être il fallair payer une license pour avoir cette fonctionnalité en plus?
Et si on pourrait virer Java et avoir le clavier d'une console qui fonctionne, ce serait pas mal non plus.
De tout coeur avec vous!
[^] # Re: HP-ILO
Posté par claudex . Évalué à 5.
Ne t'inquiète pas, chez Dell, c'est pareil.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: HP-ILO
Posté par vejmarie (site web personnel) . Évalué à 7.
Je ne peux pas juger pour Dell (le pire c'est qu'en 25 ans de carriere je n'ai jamais utilise leurs serveurs), mais en ce qui concerne iLO meme si je suis persuade que les equipes logicielles font tout ce qu'elles peuvent pour atteindre la perfection, cela reste du logiciel. Mon optique reste de penser que pouvoir offrir le choix est la meilleure maniere de repondre a ces soucis, chacun pouvant utiliser le logiciel qui correspond a son besoin et a ses aspirations. Il n'est pas sure que les logiciels libres resolvent tous les problemes, mais ils offrent la possibilite d'en comprendre la nature si on le souhaite, et de pouvoir collaborer ensemble.
[^] # Re: HP-ILO
Posté par claudex . Évalué à 5.
Je pense qu’il y a aussi beaucoup de code legacy qui n’est pas forcément facilement maintenable et une difficulté à tester. Mais j’ai quand même régulièrement le cas avec des serveurs qui viennent d’être rackés, un qui ne peut pas démarrer avec l’iDRAC.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# BBQ?
Posté par ʭ ☯ . Évalué à 1.
Excellent journal, avec quand même un terme technique non explicité : BBQ ;-)
Il semblerait que ce soit un appareil à cuisson dans lequel les aliments sont posés sur une grille. Oui, même barbecue est un mot anglais arrivé dans le français dans les années 1950…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: BBQ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 15 mai 2020 à 13:58.
Je n'ai pas compris cette phrase… tu veux dire que tu ne le découvres que maintenant ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: BBQ?
Posté par ʭ ☯ . Évalué à 2.
Oui, je ne savais pas que c'était anglais.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Mécanismes de protection ?
Posté par benoar . Évalué à 3.
Heu, perso ça m'intéresse, parce que ça fait longtemps que j'étudie le sujet et que je ne vois absolument pas comment c'est possible… Déjà rien qu'au vocabulaire que tu utilises (« protection »), ça n'augure rien de bon. Mais je suppose que tes compromis sont différents de ceux que je pense acceptables. Aurais-tu plus de détails stp ?
[^] # Re: Mécanismes de protection ?
Posté par vejmarie (site web personnel) . Évalué à 7.
On envisage plusieurs options, une qui tient la corde consiste a creer une chaine de confiance entre nous et les proprietaires. Ce n'est pas l'ideal mais cela permet de garantir la securite de la plateforme avec une minimum de modification pour les clients actuels qui souhaitent rester sur des firmware proprietaires et l'unicite de son usage. A chaque sortie d'usine les machines restent les memes, mais nous avons re-organise le firmware de telle sorte que celui-ci ait un boot loader. Ce boot loader est integre sur la flash signee et evalue le code du firmware par rapport a une clef publique de l'utilisateur et l'ID unique du systeme (chaque BMC en possede un) qui aura ete crypte avec le mecanisme du root of trust prealablement par HPE (etablissement de la chain of trust) et qui valide l'etape de chargement du code du firmware sur la machine qui lui aura ete signe avec la clef privee du proprietaire (uniquement le proprietaire peut le faire). Le mecanisme requiert qu'un canal de confiance soit etabli prealablement entre HPE et le proprietaire pour que nous puissions emettre le blob binaire crypte qui permet a la machine de demarrer avec la clef public fourni et son ID. Il faut le faire qu'une fois, a chaque update de firmware la machine reconnaitra le nouveau firmware via sa signature. Tant que la clef privee du proprietaire n'est pas compromise le systeme fonctionne. Pour changer de proprietaire, nous restons un tier de confiance, et le proprietaire precedant revoque aupres d'HPE l'integration de ca clef publique sur l'ID de la machine, permettant au futur proprietaire de faire une nouvelle demande par rapport a cet ID via une preuve de propriete.
Ca peut sembler etre une usine a gaz, mais a court terme, cela permet deja d'avancer et ne compromet pas le mode de fonctionnement deja etablit. On etudie d'autres options avec moins de dependances vis a vis d'HPE et/ou sans tier de confiance en utilisant une approche blockchain, mais on doit modifier le hardware, ce que l'on va faire, mais on est sur des cycles de dev de 3 ans sur cet asic, donc soit on attendait trois ans, soit on trouvait un compromis et je prefere avancer comme on dit !
[^] # Re: Mécanismes de protection ?
Posté par benoar . Évalué à 2.
OK donc pour reformuler en français, le « propriétaire » de la machine (je mets entre guillemets parce que pour les logiciels qui tournent dessus c'est un mensonge, il n'en est pas propriétaire du tout ; juste du matériel) peut demander gentiment à HPE de faire valider (signer) sa clé intermédiaire qui lui permettra de faire tourner le(s) firmeware(s) de son choix, pour certaines machines désignées seulement. C'est mieux que rien, mais perso c'est une telle entrave à la liberté de faire tourner ses logiciels que j'ai beaucoup de peine à appeler ça une « liberté de choix », mais bon. Encore moins de décrire la volonté de « protection » comme légitime, mais c'est mon avis perso.
Le fait que tu décrives le mécanisme en détail sans évoquer de grand système de gestion connu me fait penser que c'est une solution ad-hoc, imaginée par vous dans un coin, et ça ne me rassure pas du tout sur la maturité du truc : ça ressemble à un proto qui a de grands risques de ne jamais voir le jour. Vous basez-vous sur un dérivé de ce qui a été fait pour le Secure Boot sur UEFI (pas que ça soit un système qui ait ma sympathie, mais il a le mérite d'exister), ou alors c'est du BootGuard avec implémentation custom ? Sans parler des questions de gestion, qui sont malheureusement souvent oubliées des concepteurs de ce genre de solution parce que c'est la partie selon moi la plus importante, puisqu'elle concerne les garanties que les utilisateurs peuvent attendre d'un tel système, mais qu'en général c'est la dernière préoccupation des constructeurs. Bref, ça ressemble plus à de la poudre aux yeux qu'à un réel système qui mettrait vaguement en avant l'intérêt de l'utilisateur.
Le principe technique ne me paraît pas tant usine à gaz : les chaînes de confiance à niveaux multiples sont un classique — même si ici tu ajoutes une propriété comme l'ID de la machine —, et je comprends la volonté de rétro-compatibilité avec l'existant. Mais cette volonté de faire du spécifique est pour moi vouée à l'échec. Enfin, toutes les solutions de protection de ce genre sont pour moi pourries, donc d'un côté je suis content qu'elle échoue.
Est-ce une réelle volonté ou un affichage pour faire sembler de ce préoccuper de ce point ?
OK je suis désolé mais quand tu en arrives à sortir ça, pour moi tu es 100% dans le bullshit sans avoir compris réellement le problème. Tu es comme un certain nombre de personne à t'amuser avec de la crypto parce que c'est marrant, mais tu n'as pas compris l'essentiel des problématiques de liberté d'utilisation des machines. C'est un dilemme classique : on met des personne qui croient honnêtement œuvrer à faire des choses bien, mais qui abordent un problème sans les connaissances adéquates. Je sais que tu vas me trouver méprisant, mais je pense que tu devrais réellement te poser la question de ce que tu fais avec les techniques que tu es en train de mettre en place.
Merci en tous cas pour ces explications des mécanismes sur lesquels tu travailles.
Après, pour une note de contexte finale sur mon point de vue : perso, je trouve que la libération des firmwares a peu d'intérêt en dehors de la vérification de l'absence de fonction déloyale à l'utilisateur, et je ne cherche pas absolument à les « libérer » : en effet, ce sont des logiciels plutôt fixés et utilisés uniquement au démarrage de la machine, dont l'OS prend vite le relais. Bref, ça n'a pas un intérêt gigantesque en terme de liberté logicielle pour l'utilisateur. Et l'absence de fonction déloyale serait plutôt à chercher dans la publication de code source ou la certification par des organisme spécifique que dans la possibilité de faire tourner un firmware choisit par l'utilisateur, qui sera de toutes façons toujours une solution minoritaire et ne règle pas le problème de manière globale.
[^] # Re: Mécanismes de protection ?
Posté par Megagolgoth . Évalué à 1.
Pour linuxboot, comme le BIOS ou l'UEFI, je prends pour acquis (corrigez-moi si besoin!) qu'ils restent chargés en mémoire après le boot de l'OS. En tout cas, chargé en RAM ou pas après le boot de l'OS, il chargent certains firmware : Intel ME, carte réseau (notamment le cas sur les ordinateurs portables) et certainement d'autres. C'est donc critique avec un impact sur l'OS qui se charge après (firmware "déloyale"/frelaté).
Pour OpenBMC, comme iLO et consorts, ces systèmes sont critiques car ils ont accès, même une fois l'OS chargé, "à toute la machine", comme la RAM, le hardware (état de la carte RAID, version de son driver, par exemple), les ports USB, reboot/arrêt/démarrage etc… Ils sont également souvent en route d'office dès que l'on alimente la machine. C'est donc un composant critique.
Ce que je trouve préocuppant c'est ça :
Ca ressemble à des menottes. HP pourrait très bien interdire à un nouveau propriétaire d'utiliser la machine, par ce qu'il n'a pas acheté de MCO ou sans/pour toute autre raisons.
Voir interdire à un utilisateur, du jour au lendemain d'utiliser la machine (par ce que son propiétaire viole un droit quelconque/a des liens supposés avec une structure considéré illégale par un état, par exemple). On retrouve un peu le schéma de la musique sous DRM, non cessible sans autorisation du titulaire du copyright. Il y aussi l'histoire de l'oeuvre "1984" effacé sur des lisseuses d'un grand groupe, par ce que ce grand groupe avait perdu les droits de diffusion de l'oeuvre.
Il faut voir, c'est le cas avec Oracle (BIOS), Cisco (switch, routeur), Alcatel (PABX) et sûrement d'autres, qu'il n'est pas possible d'obtenir certains firmware sans MCO.
La blockchain peut alors paraître intéressante, mais uniquement si c'est pour de la certification-que-tout-est-bien-intègre et non du contrôle par le fabricant.
Avec des logiciels libres, il est tout à fait possible de créer une prison logiciel déloyale, cf la métaphore du marteau (plante des clous, mais peu aussi servir à faire du mal).
# HPE
Posté par Guillaume Maillard (site web personnel) . Évalué à 3.
Content de savoir que les lignes bougent dans le bon sens!
En tant qu'utilisateur final, je ne saurai que faire d'un code ouvert de microcode, car d'après ce qu'en sait (cad peu), il faut avoir accès aux documentations bas niveaux du matériel, généralement non libre et quasi-impossible à se procurer sans être fabricant/constructeur.
En revanche, il est intéressant qu'il puisse être audité niveau sécurité et aussi enfin savoir "pourquoi mes p*tins de serveurs prennent 3 minutes à démarrer" :) .
# A mort les BIOS et BMC pourris
Posté par zerodeux (site web personnel) . Évalué à 4.
Je met du Dell partout, ça juste marche mais les BIOS mettent maintenant minimum 3min à POSTer, les BMC sont des usines à gaz qui ne font pas l'essentiel de façon sécurisé et fiable, ne sont pas automatisables, ni upgradables sans s'arracher les cheveux, etc. Si HP sort des serveurs linuxboot et des BMC utilisables (en virant en particulier ce protocole immonde qu'est IPMI, merci u-bmc), je deviens HP 100% direct.
J'ai utilisé des Sun RaQ début des années 2000, le BIOS de ces bestiaux était … Linux. Je me rappelle que 48h après avoir découvert le bestiau je pouvais recompiler le boot kernel et le hacker sans aucun souci, au boot on avait direct (en 2sec) une console Linux extensible/hackable à souhait, etc. J'ai donc vu la lumière il y a presque 20 ans, et à ce jour je vois juste des UEFI et autres empilements de ROMs écrites avec les pieds (contrôleurs RAID, PXE, etc), bref c'est de plus en plus obscur, insecure et inefficace.
PS: je fais du cloud (infra) et je me moque des "trusted boot" & co. En fait le seul modèle de sécurité ou je pourrai parler de confiance sera celui d'un serveur dont je choisis et comprend le modèle de sécurité, pas celui qui m'impose sa conception du monde et ses blobs magiques.
Merci de faire avancer le "boot world", il en a tellement besoin…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.