Entrevue Lors de la conférence AWS re: Invent la semaine dernière, Le registre a demandé à Chris Schlaeger, directeur du noyau et des systèmes d'exploitation, comment le géant du cloud se protège lui-même et ses clients contre les bogues d'exécution spéculative dans les processeurs Intel.\nSchlaeger nous a dit qu'il était responsable "de la couche la plus basse de la pile logicielle qui s'exécute sur presque tous les serveurs. Nous travaillons sur des choses comme le noyau Linux, divers hyperviseurs, Xen, KVM, Firecracker si vous voulez inclure le VMM [Virtual Machine Manager] ainsi que. Et nous sommes fortement impliqués dans la définition de l'EC2 [Elastic Compute Cloud] types d'instances, en particulier pour la plate-forme accélérée. "\nIl y a quelques mois, le responsable du noyau Linux Greg Kroah-Hartman nous a dit que les infâmes bogues de Spectre, Meltdown et d'autres MDS (Microarchitectural Data Sampling) seraient "avec nous pendant longtemps", comme "de plus en plus du même type". de problèmes "sont découverts.\nSon conseil était de "désactiver [Intel’s] hyper-Threading. C'est la seule façon de résoudre certains de ces problèmes, "surtout si vous utilisez un environnement partagé – comme le cloud public.
"},{"id":"text-2","type":"text","heading":"","plain_text":"Woo-yay, les correctifs du processeur Meltdown sont ici. Maintenant, les défauts de Spectre hanteront l'industrie technologique pendant des années\nLIRE LA SUITE\nAlors, que fait AWS?\n"Greg est un bon ami à moi et je suis au courant de ses déclarations. Une des choses à garder à l'esprit, cependant, c'est qu'il représente une communauté de développeurs de noyau Linux", nous a dit Schlaeger.\n"Le noyau Linux est utilisé dans une très large gamme de systèmes et les développeurs du noyau n'ont aucun contrôle sur ce que les gens font avec leur noyau. Dans cette position, les conseils de Greg pour désactiver l'hyper-threading sont un bon outil pour vous sortir de la plupart des problèmes d'une manière simple et facile. Il ne résout pas tous les problèmes, mais il vous apporte beaucoup sur la route.","html":"Woo-yay, les correctifs du processeur Meltdown sont ici. Maintenant, les défauts de Spectre hanteront l'industrie technologique pendant des années\nLIRE LA SUITE\nAlors, que fait AWS?\n"Greg est un bon ami à moi et je suis au courant de ses déclarations. Une des choses à garder à l'esprit, cependant, c'est qu'il représente une communauté de développeurs de noyau Linux", nous a dit Schlaeger.\n"Le noyau Linux est utilisé dans une très large gamme de systèmes et les développeurs du noyau n'ont aucun contrôle sur ce que les gens font avec leur noyau. Dans cette position, les conseils de Greg pour désactiver l'hyper-threading sont un bon outil pour vous sortir de la plupart des problèmes d'une manière simple et facile. Il ne résout pas tous les problèmes, mais il vous apporte beaucoup sur la route.
"},{"id":"text-3","type":"text","heading":"","plain_text":"Mais il y a un petit problème …","html":"Mais il y a un petit problème …
"},{"id":"text-4","type":"text","heading":"","plain_text":""Malheureusement, lorsque vous faites cela, vous perdez environ 30 à 40% des performances du serveur. Mettez-vous à ma place. Ce n'est pas une option très intéressante. Nous avons des clients qui ont nos types d'instances les plus importants. Les bases de données en mémoire, par exemple, sont mis à l'échelle pour maximiser la boîte. Si je retire 30 à 40 pour cent, je tue leur application.\n"A notre taille, nous avons de nombreux clients dans cette situation et il n'est pas financièrement intéressant pour nous de simplement désactiver l'hyper-threading.\n"C'est là que vous devez regarder les petits caractères de ces [vulnerabilities]. Ils viennent avec beaucoup de détails. Même les détails fournis par Intel ne suffisent souvent pas pour comprendre ce qui se passe et dans quelle situation particulière vous êtes ou non affecté. Donc, au cours des deux dernières années, j'ai une grande équipe d'experts en sécurité qui ne font rien d'autre que de faire face aux retombées. Ils s'assurent que dans notre environnement, nous pouvons toujours le garder en sécurité sans désactiver l'hyper-threading. "\nSchlaeger a ajouté: "C'est une bataille quotidienne que nous devons mener. Dans notre environnement, nous savons bien ce que nous faisons, comment nous utilisons l'hyperviseur, comment les invités sont affectés aux cœurs physiques. Nous avons trouvé un moyen de garder les choses en sécurité donc il n'y a pas de canaux secondaires pour l'existant [issues].\n"Par exemple, nous avons modifié l'ordonnanceur qui se trouvait dans le noyau Linux ainsi que dans l'hyperviseur pour garantir que les invités ne s'exécutent jamais en même temps sur une paire de base. Cela a coûté un peu de performances, mais c'était surtout gérable pour nous."\nAWS a essayé d'obtenir ses correctifs en amont mais, parce qu'ils sont conçus pour le cas d'utilisation étroit des services AWS, il a été difficile de les faire accepter.\n"La communauté du noyau n'était pas trop enthousiaste à l'idée de prendre les correctifs", nous a expliqué Schlaeger. "Nous avons eu un tas de discussions avec Peter Zijlstra [kernel maintainer at Intel] sur ce. Il a une approche alternative[es]. Le problème que nous devons résoudre est légèrement différent de ce que la communauté doit résoudre car elle doit couvrir tous les cas d'utilisation possibles et le rendre relativement idiot.\n«J'espère que nous trouverons un accord, car nous avons très peu d'intérêt à porter nos propres correctifs élaborés, en particulier dans le planificateur du noyau. C'est juste un travail que nous devons faire chaque fois que nous faisons une nouvelle version du noyau. Le faire en amont serait la solution idéale pour nous. "","html":""Malheureusement, lorsque vous faites cela, vous perdez environ 30 à 40% des performances du serveur. Mettez-vous à ma place. Ce n'est pas une option très intéressante. Nous avons des clients qui ont nos types d'instances les plus importants. Les bases de données en mémoire, par exemple, sont mis à l'échelle pour maximiser la boîte. Si je retire 30 à 40 pour cent, je tue leur application.\n"A notre taille, nous avons de nombreux clients dans cette situation et il n'est pas financièrement intéressant pour nous de simplement désactiver l'hyper-threading.\n"C'est là que vous devez regarder les petits caractères de ces [vulnerabilities]. Ils viennent avec beaucoup de détails. Même les détails fournis par Intel ne suffisent souvent pas pour comprendre ce qui se passe et dans quelle situation particulière vous êtes ou non affecté. Donc, au cours des deux dernières années, j'ai une grande équipe d'experts en sécurité qui ne font rien d'autre que de faire face aux retombées. Ils s'assurent que dans notre environnement, nous pouvons toujours le garder en sécurité sans désactiver l'hyper-threading. "\nSchlaeger a ajouté: "C'est une bataille quotidienne que nous devons mener. Dans notre environnement, nous savons bien ce que nous faisons, comment nous utilisons l'hyperviseur, comment les invités sont affectés aux cœurs physiques. Nous avons trouvé un moyen de garder les choses en sécurité donc il n'y a pas de canaux secondaires pour l'existant [issues].\n"Par exemple, nous avons modifié l'ordonnanceur qui se trouvait dans le noyau Linux ainsi que dans l'hyperviseur pour garantir que les invités ne s'exécutent jamais en même temps sur une paire de base. Cela a coûté un peu de performances, mais c'était surtout gérable pour nous."\nAWS a essayé d'obtenir ses correctifs en amont mais, parce qu'ils sont conçus pour le cas d'utilisation étroit des services AWS, il a été difficile de les faire accepter.\n"La communauté du noyau n'était pas trop enthousiaste à l'idée de prendre les correctifs", nous a expliqué Schlaeger. "Nous avons eu un tas de discussions avec Peter Zijlstra [kernel maintainer at Intel] sur ce. Il a une approche alternative[es]. Le problème que nous devons résoudre est légèrement différent de ce que la communauté doit résoudre car elle doit couvrir tous les cas d'utilisation possibles et le rendre relativement idiot.\n«J'espère que nous trouverons un accord, car nous avons très peu d'intérêt à porter nos propres correctifs élaborés, en particulier dans le planificateur du noyau. C'est juste un travail que nous devons faire chaque fois que nous faisons une nouvelle version du noyau. Le faire en amont serait la solution idéale pour nous. "
"},{"id":"text-5","type":"text","heading":"","plain_text":"Chris Schlaeger, directeur AWS du noyau et des systèmes d'exploitation","html":"Chris Schlaeger, directeur AWS du noyau et des systèmes d'exploitation
"},{"id":"text-6","type":"text","heading":"","plain_text":"Responsabilité personnelle","html":"Responsabilité personnelle
"},{"id":"text-7","type":"text","heading":"","plain_text":"Le travail qu'AWS a fait ne dégage pas la responsabilité de ses clients de prendre des précautions, a déclaré Schlaeger. "Nous avons fait le travail pour protéger notre environnement, mais le noyau à l'intérieur de l'instance, ou le noyau du système d'exploitation – car il affecte également Windows – nécessitent des modifications du noyau.\n"Ce n'est pas seulement quelque chose que nous pouvons résoudre. Nous nous assurons que notre infrastructure est sûre, mais comme les clients ont un accès relativement direct au CPU, ils sont affectés. Ce dont ils n'ont pas à s'inquiéter, ce sont les mises à jour du microcode. Nous appliquons toutes les mises à jour du microcode pour eux. "\nUn autre facteur de sécurité de la plate-forme AWS est l'hyperviseur utilisé. "Nous avons deux hyperviseurs principaux. C'est l'hyperviseur Xen et l'hyperviseur Nitro qui est une version fortement personnalisée de KVM", a déclaré Schlaeger.\nDans le système Nitro, l'hyperviseur fonctionne sur une carte complémentaire. Nitro utilise un noyau Linux minimal alors que "dans le monde Xen, vous avez une instance ou un domaine spécial qui est en grande partie une distribution Linux complète. Il contient environ 300 packages RPM. C'est difficile à maintenir. Vous l'isolez, mais vous devriez quelqu'un y va, vous avez un accès root complet au système. "\nIl y a des implications sur la façon dont les deux hyperviseurs sont gérés. Avec Xen, "les employés pouvaient se connecter avec SSH à un serveur pour effectuer des tâches administratives. C'est parfois utile, mais très puissant. J'adore le vieux dicton, dès que quelqu'un se connecte avec des autorisations root sur un serveur, toutes les connaissances précédentes de tout le monde sinon à quoi ressemble ce serveur, est détruit.","html":"Le travail qu'AWS a fait ne dégage pas la responsabilité de ses clients de prendre des précautions, a déclaré Schlaeger. "Nous avons fait le travail pour protéger notre environnement, mais le noyau à l'intérieur de l'instance, ou le noyau du système d'exploitation – car il affecte également Windows – nécessitent des modifications du noyau.\n"Ce n'est pas seulement quelque chose que nous pouvons résoudre. Nous nous assurons que notre infrastructure est sûre, mais comme les clients ont un accès relativement direct au CPU, ils sont affectés. Ce dont ils n'ont pas à s'inquiéter, ce sont les mises à jour du microcode. Nous appliquons toutes les mises à jour du microcode pour eux. "\nUn autre facteur de sécurité de la plate-forme AWS est l'hyperviseur utilisé. "Nous avons deux hyperviseurs principaux. C'est l'hyperviseur Xen et l'hyperviseur Nitro qui est une version fortement personnalisée de KVM", a déclaré Schlaeger.\nDans le système Nitro, l'hyperviseur fonctionne sur une carte complémentaire. Nitro utilise un noyau Linux minimal alors que "dans le monde Xen, vous avez une instance ou un domaine spécial qui est en grande partie une distribution Linux complète. Il contient environ 300 packages RPM. C'est difficile à maintenir. Vous l'isolez, mais vous devriez quelqu'un y va, vous avez un accès root complet au système. "\nIl y a des implications sur la façon dont les deux hyperviseurs sont gérés. Avec Xen, "les employés pouvaient se connecter avec SSH à un serveur pour effectuer des tâches administratives. C'est parfois utile, mais très puissant. J'adore le vieux dicton, dès que quelqu'un se connecte avec des autorisations root sur un serveur, toutes les connaissances précédentes de tout le monde sinon à quoi ressemble ce serveur, est détruit.
"},{"id":"text-8","type":"text","heading":"","plain_text":"Fidèle à son nom, la faille CPU Intel ZombieLoad revient avec une nouvelle variante\nLIRE LA SUITE\n"Avoir autant de serveurs, ce n'est pas quelque chose que nous pouvons nous permettre. Le système Nitro est conçu pour avoir une API très spécifique. Il est authentifié, nous pouvons l'enregistrer, nous savons exactement qui a fait quoi et quelles sont les actions. Je peux obtenir quelques informations de débogage, je peux arrêter une instance, je peux en démarrer une autre, et c'est tout. "\nBien que Nitro semble préférable, Schlaeger a déclaré: "Nous n'avons aucune intention de basculer les systèmes qui exécutent Xen vers Nitro. Nitro n'est pas seulement un hyperviseur et ce n'est pas un remplacement individuel de Xen."\nCes efforts de sécurité sont-ils rassurants? Il est clair qu'AWS accorde une attention particulière aux problèmes d'Intel (et nous avons appris séparément que la plupart des serveurs AWS, mais pas tous, exécutent des processeurs Intel), mais que le recours extrême consistant à désactiver l'hyper-threading est trop coûteux à envisager.\nEn supposant qu'AWS a tout fait correctement, il appartient toujours à ses clients de déterminer s'ils exécutent des charges de travail susceptibles d'être vulnérables à ce type d'attaque et, le cas échéant, de prendre les mesures appropriées. Un autre avantage pour les serveurs sans serveur, peut-être.\nNous ne choisissons pas AWS. Nous avons posé la même question à Microsoft et à Google et nous vous répondrons bientôt. ®","html":"Fidèle à son nom, la faille CPU Intel ZombieLoad revient avec une nouvelle variante\nLIRE LA SUITE\n"Avoir autant de serveurs, ce n'est pas quelque chose que nous pouvons nous permettre. Le système Nitro est conçu pour avoir une API très spécifique. Il est authentifié, nous pouvons l'enregistrer, nous savons exactement qui a fait quoi et quelles sont les actions. Je peux obtenir quelques informations de débogage, je peux arrêter une instance, je peux en démarrer une autre, et c'est tout. "\nBien que Nitro semble préférable, Schlaeger a déclaré: "Nous n'avons aucune intention de basculer les systèmes qui exécutent Xen vers Nitro. Nitro n'est pas seulement un hyperviseur et ce n'est pas un remplacement individuel de Xen."\nCes efforts de sécurité sont-ils rassurants? Il est clair qu'AWS accorde une attention particulière aux problèmes d'Intel (et nous avons appris séparément que la plupart des serveurs AWS, mais pas tous, exécutent des processeurs Intel), mais que le recours extrême consistant à désactiver l'hyper-threading est trop coûteux à envisager.\nEn supposant qu'AWS a tout fait correctement, il appartient toujours à ses clients de déterminer s'ils exécutent des charges de travail susceptibles d'être vulnérables à ce type d'attaque et, le cas échéant, de prendre les mesures appropriées. Un autre avantage pour les serveurs sans serveur, peut-être.\nNous ne choisissons pas AWS. Nous avons posé la même question à Microsoft et à Google et nous vous répondrons bientôt. ®
"},{"id":"text-9","type":"text","heading":"","plain_text":"Click to rate this post!\n \n [Total: 0 Average: 0]","html":"Click to rate this post!\n \n [Total: 0 Average: 0]
"}],"sections":[{"id":"text-1","heading":"Text","content":"Entrevue Lors de la conférence AWS re: Invent la semaine dernière, Le registre a demandé à Chris Schlaeger, directeur du noyau et des systèmes d'exploitation, comment le géant du cloud se protège lui-même et ses clients contre les bogues d'exécution spéculative dans les processeurs Intel.\nSchlaeger nous a dit qu'il était responsable "de la couche la plus basse de la pile logicielle qui s'exécute sur presque tous les serveurs. Nous travaillons sur des choses comme le noyau Linux, divers hyperviseurs, Xen, KVM, Firecracker si vous voulez inclure le VMM [Virtual Machine Manager] ainsi que. Et nous sommes fortement impliqués dans la définition de l'EC2 [Elastic Compute Cloud] types d'instances, en particulier pour la plate-forme accélérée. "\nIl y a quelques mois, le responsable du noyau Linux Greg Kroah-Hartman nous a dit que les infâmes bogues de Spectre, Meltdown et d'autres MDS (Microarchitectural Data Sampling) seraient "avec nous pendant longtemps", comme "de plus en plus du même type". de problèmes "sont découverts.\nSon conseil était de "désactiver [Intel’s] hyper-Threading. C'est la seule façon de résoudre certains de ces problèmes, "surtout si vous utilisez un environnement partagé – comme le cloud public."},{"id":"text-2","heading":"Text","content":"Woo-yay, les correctifs du processeur Meltdown sont ici. Maintenant, les défauts de Spectre hanteront l'industrie technologique pendant des années\nLIRE LA SUITE\nAlors, que fait AWS?\n"Greg est un bon ami à moi et je suis au courant de ses déclarations. Une des choses à garder à l'esprit, cependant, c'est qu'il représente une communauté de développeurs de noyau Linux", nous a dit Schlaeger.\n"Le noyau Linux est utilisé dans une très large gamme de systèmes et les développeurs du noyau n'ont aucun contrôle sur ce que les gens font avec leur noyau. Dans cette position, les conseils de Greg pour désactiver l'hyper-threading sont un bon outil pour vous sortir de la plupart des problèmes d'une manière simple et facile. Il ne résout pas tous les problèmes, mais il vous apporte beaucoup sur la route."},{"id":"text-3","heading":"Text","content":"Mais il y a un petit problème …"},{"id":"text-4","heading":"Text","content":""Malheureusement, lorsque vous faites cela, vous perdez environ 30 à 40% des performances du serveur. Mettez-vous à ma place. Ce n'est pas une option très intéressante. Nous avons des clients qui ont nos types d'instances les plus importants. Les bases de données en mémoire, par exemple, sont mis à l'échelle pour maximiser la boîte. Si je retire 30 à 40 pour cent, je tue leur application.\n"A notre taille, nous avons de nombreux clients dans cette situation et il n'est pas financièrement intéressant pour nous de simplement désactiver l'hyper-threading.\n"C'est là que vous devez regarder les petits caractères de ces [vulnerabilities]. Ils viennent avec beaucoup de détails. Même les détails fournis par Intel ne suffisent souvent pas pour comprendre ce qui se passe et dans quelle situation particulière vous êtes ou non affecté. Donc, au cours des deux dernières années, j'ai une grande équipe d'experts en sécurité qui ne font rien d'autre que de faire face aux retombées. Ils s'assurent que dans notre environnement, nous pouvons toujours le garder en sécurité sans désactiver l'hyper-threading. "\nSchlaeger a ajouté: "C'est une bataille quotidienne que nous devons mener. Dans notre environnement, nous savons bien ce que nous faisons, comment nous utilisons l'hyperviseur, comment les invités sont affectés aux cœurs physiques. Nous avons trouvé un moyen de garder les choses en sécurité donc il n'y a pas de canaux secondaires pour l'existant [issues].\n"Par exemple, nous avons modifié l'ordonnanceur qui se trouvait dans le noyau Linux ainsi que dans l'hyperviseur pour garantir que les invités ne s'exécutent jamais en même temps sur une paire de base. Cela a coûté un peu de performances, mais c'était surtout gérable pour nous."\nAWS a essayé d'obtenir ses correctifs en amont mais, parce qu'ils sont conçus pour le cas d'utilisation étroit des services AWS, il a été difficile de les faire accepter.\n"La communauté du noyau n'était pas trop enthousiaste à l'idée de prendre les correctifs", nous a expliqué Schlaeger. "Nous avons eu un tas de discussions avec Peter Zijlstra [kernel maintainer at Intel] sur ce. Il a une approche alternative[es]. Le problème que nous devons résoudre est légèrement différent de ce que la communauté doit résoudre car elle doit couvrir tous les cas d'utilisation possibles et le rendre relativement idiot.\n«J'espère que nous trouverons un accord, car nous avons très peu d'intérêt à porter nos propres correctifs élaborés, en particulier dans le planificateur du noyau. C'est juste un travail que nous devons faire chaque fois que nous faisons une nouvelle version du noyau. Le faire en amont serait la solution idéale pour nous. ""},{"id":"text-5","heading":"Text","content":"Chris Schlaeger, directeur AWS du noyau et des systèmes d'exploitation"},{"id":"text-6","heading":"Text","content":"Responsabilité personnelle"},{"id":"text-7","heading":"Text","content":"Le travail qu'AWS a fait ne dégage pas la responsabilité de ses clients de prendre des précautions, a déclaré Schlaeger. "Nous avons fait le travail pour protéger notre environnement, mais le noyau à l'intérieur de l'instance, ou le noyau du système d'exploitation – car il affecte également Windows – nécessitent des modifications du noyau.\n"Ce n'est pas seulement quelque chose que nous pouvons résoudre. Nous nous assurons que notre infrastructure est sûre, mais comme les clients ont un accès relativement direct au CPU, ils sont affectés. Ce dont ils n'ont pas à s'inquiéter, ce sont les mises à jour du microcode. Nous appliquons toutes les mises à jour du microcode pour eux. "\nUn autre facteur de sécurité de la plate-forme AWS est l'hyperviseur utilisé. "Nous avons deux hyperviseurs principaux. C'est l'hyperviseur Xen et l'hyperviseur Nitro qui est une version fortement personnalisée de KVM", a déclaré Schlaeger.\nDans le système Nitro, l'hyperviseur fonctionne sur une carte complémentaire. Nitro utilise un noyau Linux minimal alors que "dans le monde Xen, vous avez une instance ou un domaine spécial qui est en grande partie une distribution Linux complète. Il contient environ 300 packages RPM. C'est difficile à maintenir. Vous l'isolez, mais vous devriez quelqu'un y va, vous avez un accès root complet au système. "\nIl y a des implications sur la façon dont les deux hyperviseurs sont gérés. Avec Xen, "les employés pouvaient se connecter avec SSH à un serveur pour effectuer des tâches administratives. C'est parfois utile, mais très puissant. J'adore le vieux dicton, dès que quelqu'un se connecte avec des autorisations root sur un serveur, toutes les connaissances précédentes de tout le monde sinon à quoi ressemble ce serveur, est détruit."},{"id":"text-8","heading":"Text","content":"Fidèle à son nom, la faille CPU Intel ZombieLoad revient avec une nouvelle variante\nLIRE LA SUITE\n"Avoir autant de serveurs, ce n'est pas quelque chose que nous pouvons nous permettre. Le système Nitro est conçu pour avoir une API très spécifique. Il est authentifié, nous pouvons l'enregistrer, nous savons exactement qui a fait quoi et quelles sont les actions. Je peux obtenir quelques informations de débogage, je peux arrêter une instance, je peux en démarrer une autre, et c'est tout. "\nBien que Nitro semble préférable, Schlaeger a déclaré: "Nous n'avons aucune intention de basculer les systèmes qui exécutent Xen vers Nitro. Nitro n'est pas seulement un hyperviseur et ce n'est pas un remplacement individuel de Xen."\nCes efforts de sécurité sont-ils rassurants? Il est clair qu'AWS accorde une attention particulière aux problèmes d'Intel (et nous avons appris séparément que la plupart des serveurs AWS, mais pas tous, exécutent des processeurs Intel), mais que le recours extrême consistant à désactiver l'hyper-threading est trop coûteux à envisager.\nEn supposant qu'AWS a tout fait correctement, il appartient toujours à ses clients de déterminer s'ils exécutent des charges de travail susceptibles d'être vulnérables à ce type d'attaque et, le cas échéant, de prendre les mesures appropriées. Un autre avantage pour les serveurs sans serveur, peut-être.\nNous ne choisissons pas AWS. Nous avons posé la même question à Microsoft et à Google et nous vous répondrons bientôt. ®"},{"id":"text-9","heading":"Text","content":"Click to rate this post!\n \n [Total: 0 Average: 0]"}],"media":{"primary_image":"https://tutos-gameserver.fr/wp-content/uploads/2019/12/aws.jpg"},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2019/12/12/une-grande-equipe-dexperts-en-securite-soccupe-des-retombees-de-spectre-des-defauts-de-fusion-%e2%80%a2-le-registre-bien-choisir-son-serveur-d-impression/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/12/12/une-grande-equipe-dexperts-en-securite-soccupe-des-retombees-de-spectre-des-defauts-de-fusion-%e2%80%a2-le-registre-bien-choisir-son-serveur-d-impression/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/12/12/une-grande-equipe-dexperts-en-securite-soccupe-des-retombees-de-spectre-des-defauts-de-fusion-%e2%80%a2-le-registre-bien-choisir-son-serveur-d-impression/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}