vu que tu ne maîtrises pas l'ordre d'affichage des messages
Les rares fois ou j'ai debugé du multithreadé avec des printf sur la sortie standard, j'étais bien content de ne pas maitriser l'ordre d'affichage. En fait c'était même un peut le but. C'est là qu'on arrivait à de jolis use-case avec un affichage qui permettait de savori quel thread avait fait quoi avant/après tel autre thread.
Le gros défaut de la sortie standard c'est qu'ecrire dessus c'est non atomique, il peut donc se passer des choses entre le début et la fin de l'écriture (interrupt, segfault d'un autre thread qui plie le process etc.)
Gros problème pour faire du debug avec exclusivement des commandes atomiques il faut se lever de bonne heure (que ce soit avec printf, GDB ou des buffers extérieurs).
On peut tricher avec un process extérieur et des IPC mais généralement on obtient des résultats assez variables.
L'idéal c'est un simulateur qu'on peut mettre en pause, retour arrière, avance rapide quand on veut. Mais là il vaut mieux avoir de la ram et de la puissance CPU à disposition, parceque ca risque de ramer (surtout si vous avez des dizaines et des dizaines de threads).
Pour finir il est important de bien se rendre compte d'un chose : il ets impossible d'écrire un debuggueur parfait. Etre capable d'écrire un programme qui va trouver toutes les failles dans n'importe quel code est équivalent à écrire un programme capable de detecter si n'importe quel code va se terminer. Pour debugguer rien en remplace donc le cerveau. Certaines méthodes vont marcher, d'autres pas du tout mais il est assez difficile de savoir à priori lesquelles.
Après avoir vainement cherché un « GDBdebugging considered harmful » j'en suis arrivé à la conclusion qu'il n'existait pas et j'ai donc décidé de l'écrire moi même.
Restons clair, si GDB est un excellent outil pour former les programmeurs débutants à la notion de pointeur et de libération de mémoire, il ne devrait jamais être utilisé pour quoi que ce soit d'autre. Donc passé deux ans à faire du C de façon intensive jetez le aux oubliettes et utilisez des appels intracode pour vous informer des problèmes rencontrés (printf est une bonne solution dans 90% des cas)
Les inconvennients majeurs de GDB :
- Un programme C/C++ compilé en mode "debug" ne se comporte pas (parfois pas du tout) comme le même programme compilé en mode standard. les différences principales sont :
* différence dans le link des bibliothèques. Le simple fait d'activer GDB dans un programme qui lie une bibliothèque compilée sans les options de debug peut faire apparaitre/disparaitre pas mal de bugs.
* différence dans la signature des pointeurs de fonctions. Si vous avez le moindre paramêtre système dans votre fonction, il y a 9 chances sur 10 pour que sa signature change après un passage de GDB. Cela peut également faire apparaitre/disparaitre un paquet de bugs. (des segfault souvent)
* remontée de tout un tas d'appels systèmes pour suivre le déroulement du programme qui n'existent pas dans les versions compilées en standard.
- Dans la plupart des programmes, GDB ne peut pas grand chose pour vous :
* Oubliez le mot clef "volatile" à moins de s'en servir exclusivement pour GDB. (Bon vous allez me dire que de toute façon vous ne connaissiez pas le keyword volatile)
* Oubliez les interruptions systèmes, notamment alarm, gettime et sleep. Certains messages passent, d'autres sont trappés par GDB directemetn sans jamais atteindre votre programme.
* GDB est totalement inutile en cas de programmation concurrente/parallèle. Il ne comprend rien au fichiers mappés en mémoire par un autre process et a du mal avec les messages IPC/ITC (com entre processes, com entre threads) un peu complexe.
* Si pour une raison quelconque, la mémoire allouée par un process est désallouée par un autre, c'est festival.
* Pour les raisons évoquée plus haut n'essayez même pas d'utiliser GDB en dehors du userland, vous allez vous faire mal à le kernel.
- GDB vous empêche de comprendre ce qui se passe vraiment.
* GDB ne comprend pas le code, il le trace. Si vous avez fait une erreur conceptuelle quelque part, GDB vous maintiendra dans l'illusion quand allouant un octet mémoire de plus ou en castant un peu plus violamment une variable ca marche.
* GDB ne comprend pas ce que vous cherchez à faire. A moins de truffer le code de volatile dédiés, GDB va vous aider à debugger les différents cas de figures un par un. A moins d'être très propre, très rigoureux et pas pressé par le temps, votre code (si il est imposant) ressemblera rapidement un un patchwork de verrues et de pansements. On reconnait le code des afficionados de GDB aux nombres de tests qu'il y a dans le code.
* GDB check, trace et valide le code. Il est totalement insensible au système et à l'environnement de la machine. Si votre programme plante suite à un appel système, GDB vous permettra de trouver ou dans le code il faut contourner l'appel système. Mais il ne sera d'aucune utilité sur le pourquoi, le comment et la méthode à adopter pour traiter/ignorer l'appel système.
En bref GDB c'est bien pour les petites applis monotache, mono-utilisateur, monoprocess qui n'ont pas besoin des fonctions systèmes ou d'appels complexes à des bibliothèques extérieures.
GCC 4 stable, OMD oui je viens de voir ça... et hop c'est parti pour 180h \o/
Revient ici malheureux !
A moins que tu veuilles jouer avec les slots sur toutes tes libs dès qu'il y a du C++ dans l'air je te conseille de patienter un peu avant de te jeter sur GCC 4.x
Ensuite, par défaut GCC 4.x est présent mais ne sert pas à grand chose, il est juste mis dans un slot à coté et c'ets toujours le 3 qui fait le boulot de compil.
Pour finir je te conseille vivement de quickpackager (le premier qui me dit qu'en francais ils faut dire prestempaqueter gagne un cadeau surprise) deux trois trucs avant de te lancer dans les compils. parmis lesquels (dans l'ordre d'importance) : la libstdc++, Xorg-x11, gcc 3.x et KDE si besoin
Après je te laisse le bonheur de te rendre compte qu'il y a quand même pas mal de trucs qui compilent assez moyennement avec GCC4
Un bon test à faire serait de voir si tu peux monter tes disques sur ton OS Linux, et ensuite essayer d'ouvrir (avec vlc, mais ca doit passer aussi avec les autres) les .vob contenus dans VIDEO_TS
Ces .vob devraient s'ouvrir et être lus par VLC (si le fichier est protégé CSS ca fera de gros blocs verts, mais au moins on saura que les données sont accessibles.)
Les DVD sont extrèmement sensibles lors de la gravure à tout un tas de petits détails.
La qualité du graveur par exemple influe beaucoup sur le résultat, le support aussi. Si vous voulez obtenir des DVD lisible facilement sur autre chose que la plateforme de gravure, voici rapidement les recommandations que l'on peut faire :
a) évitez les DVD+R\RW. Les DVD+ sont beaucoup plus compelxes à lire que les DVD- . De fait on peut faire nettement plus de choses avec (multi-mode, gravure depuis un point arbitraire, multisession détaché etc.) MAIS de part cette complexité pas mal de lecteurs même sois-disant compatible DVD+ se prennent les pieds dans les différents catalogues et les métadonnées.
(Par contre les DVD+ c'ets le top pour sauvegarder des données destinées à être lues exclusivemetn sur ordi)
b) Si possible limiter la vitesse de gravure. Graver un DVD en 8x est rarement une bonne idée. Lors de la gravure un DVD va déjà générer des erreurs en pagaille (toutes corrigées par les différents CRC si la gravure s'est bien terminée) , ca n'est pas la peine de prendre plus de risque en poussant le lecteur au maximum. La vitesse qui marchent très bien sur mon plextor sous Linux c'est 1,43x (le minimum). Si je passe à 2 ou 4x mon DVD reste lisible mais les erreurs correctibles se multiplient.
c) Prenez un support de bonne qualité. Les DVD gravables noname ont les mêmes inconvennients que la gravure à grande vitesse : multiplication des erreurs de gravure. Personnellement je recommande les DVD de marque Verbatim ou Fujifilm pour les produits finis destinés à être distribués, ils passent bien avec à peu près tous les graveurs que j'ai essayé. Si ca fait trop mal au porte-monnaie, j'ai aussi obtenu de bons résultats avec les TDK, mais c'était il y a un moment.
En fait il faut essayer de mettre la main sur des disques fabriquées par Tayo yunden ou à défaut par Mitsubishi Chemicals. Le site cdfreaks.com est un bon moyen de comparer les résultats et de choisir une marque de référence soi-même.
d) Pas de multi-sessions. Les DVD-R sont nuls en multi-session. Si vous voulez faire du multi-session prenez des DVD+, mais comme dit dans le a) ils sont plus complexes à lire et donc on prend le risque d'avoir des DVD lisibles sur un nombr eplus limité de plateformes.
e) Si possible faites la finalisation du disque sur l'ordi plutôt que sur la platine. Certaines platines ont uen façon assez spéciale de refermer le catalogue (probablement pour ajouter pleins de fonctionnalités rigolotes utilisable seulement par la platine elle-même). Tant pis pour les fonctionnalités non standard.
Normalement en respectant ces consignes on arrive à faire des DVD relativement bien compatibles avec la plupart des platines.
Soyons clair, au niveau desktop MS fait son chiffre d'affaire grace à deux produits : l'OS windows et la suite office. De fait ils n'ont qu'une chose à éviter absolument : que les gens changent d'OS pour un OS libre ou qu'ils utilisent une autre suite que la suite office.
Or là on vient de leur donner sur un plateau, avec le renforcement du DMCA aux US et l'application des lois sur la sécurité numérique en Europe, un monopole sur la lecture des médias nouvelle génération. Entre les lecteurs Matsushita/panasonic qui refusent les accès RAW aux DVD de la mauvaise zone et l'impossibilité de lire les HDVD/BLU-Ray sur une plateforme ouverte ils sont aux anges.
De fait la possiblité que les particuliers quittent Windows pour Linux dans les 5 années à venir se réduit comme peau de chagrin. Une fois fini les bouteilles de champagnes il est normal que les pontes de Microsoft se demandent comment retirer les deux ou trois derniers atours du libre. S'assurer que Thunderbird et Firefox tournent sous Vista est une bonne solution. Je epnse qu'ils vont même tout faire pour que Firefox et Thunderbird aient sous Vista de chouettes fonctionnalités qui n'existeront pas sous Linux avant quelques années et hop c'est dans la poche.
Bien sur c'est mon opinion personelle, mais ce mouvement ne me surprend pas outre mesure. Rien de nouveau sous le soleil, "embrace and extend" comme ils disent.
Le Wushu (kung fu étant un terme générique en chinois qui veut à la fois tout et rien dire - on peut considerer uen façon spéciale de faire la cuisine comme un kung-fu) est un art très complet, mais qui requiert une bonne souplesse.
C'est un art assez sympa à apprendre, surtout si le temple/gymnase ou tu l'apprends enseigne aussi le maniement des armes en parallèle. Le truc c'est que le Wushu est assez pénible si on tombe sur un maitre rigoureux. Il vaut mieux avoir une assez bonne condition physique et pas mal de souplesse au moment ou on commence sinon on peut avoir vraiment du mal à finir une séance (personellement j'avais les muscles lombaires trop faible et la première fois j'ai même pas pu finir l'échauffement tellement j'avais mal).
Au niveau combat le Wushu est probablement l'art qui tient le mieux sa position entre équilibre et force. A savoir que l'on tappe comme des bourrins façon Karate tout en gardant un bon équilibre sur ses pieds façon aikido/judo.
J'aime beaucoup cet art, mais il faut reconnaitre qu'il a deux défauts : le premier est qu'il doit normalement s'accompagner de longues phases de reflexion et de méditation, et qui en 2x2h par semaine est pas évident, on s'éloigne donc forcément de l'esprit des maitres (sauf à aller dans un temple Shaolin, mais c'est pas donné à tout le monde). Le deuxième c'est que le Wushu vise à faire naitre des reflexes assez brutaux quand on est en situation de combat. On s'entrainne pour celà à répeter les mêmes enchainements sur des PAO pendant des cours entiers. Mais le problème est qu'en situation d'agression, l'enchainement peut parfois sortir "tout seul", ce qui est généralement une très mauvaise idée. Ca vient peut être du maitre que j'ai eu, mais je pense qu'il manque une partie du self control que l'on peut aquérir dans les arts japonais, et comme le Wushu est assez destructeur...
Ceci dit, c'est très très sympa, notamment au niveau de ce que l'on arrive à faire après un ou deux ans de pratique régulière.
Parce que le lecteur de DVD gere aussi le CSS et qu'il ne te laissera pas avoir le contenue RAW du disque ...
Encore très très rare. A ma connaissance seul certains lecteurs de chez panasonic/matshita sont capable de refuser l'accès raw (et encore seulement sur les zones qu'ils considèrent comme invalides). Sinon tous les autres lecteurs ou presque fonctionnent très bien en accès raw (c'est d'ailleurs ce qui a fait le succès de DeCSS). La copie raw marche dans 99% des cas.
Bon je n'ai pas eu d eproblèmes poru le remboursement. Je m'étais préparé psychologiquement à devoir mener une guerre de mauvaise fois avec un chef de rayon hargneux mais je m'étais trompé.
En 3 minutes l'affaire était pliée et le bon d'achat dans ma poche (j'imagine qu'un remboursement en liquide ou en retour sur ma CB aurait été plus problématique, mais je suis peut être mauvaise langue)
Donc voilà un CD déballé qui va faire tache sur la liste des produits.
A part l'album "Enter" (très bon, mais pas super bien produit), Within Temptation ca ne joue pas vraiment dans la même cour. Les mélodies sont nettement plus simple (plus pop diraientt les détracteurs) et Sharon a quand même pas mal calmé le jeu sur sa voix (qui reste très belle, mais nettement moins puissante qu'elle n'avait pu l'être).
Et puis depuis l'album Silent Force on sent un revirement très net vers le POP/Nu-Metal (déjà un poil ammorcé avec la reprise de Kate Bush - "runing up that hill"). Donc mettre Within Temptation et Evanescence dans le même sac ca n'est pas à proprement parlé abbhérant.
after forever a une jolie (pouf ?) chanteuse et ils le montrent !
Si tu fais allusion à la pochette de remagine, effectivement c'est pas terrible. Ceci étant Floor Jansen ne rentre pas vraiment dans la catégorie des "poufiasses". Son imposante stature, sa voix et ses yeux la protègent ad vitam eternam de ce status.
mais si ya pas de tel logo, ils peuvent vendre ce qu'ils veulent.
Et non, tromperie sur la marchandise, défaut d'information, matériel deffectueux tout ça. C'est vendu au stand des CD, au millieu des CD et ca n'en est pas un. La loi protège le consomatuer de ce genre de cas.
D'ailleurs, si tu regarde bien, il me semble que la plupart des "cds" copy controlled n'ont plus le logo CD.
Normalement aucun, généralement pour protégé un CD on est obligé de sortir des normes assez strictes du livre blanc de Phillips.
Et donc on perd le droit à l'appelation Compact Disc (tout court).
Moi, c'est pas pour ça ! ... On dirait le groupe pour ados Evanescence.
Euh... Tu as pas du écouter plus de trente secondes d'AFTER FOREVER dans ta vie, et encore probablement "Being Everyone" sur l'album Reimagine, parceque sinon...
After Forever avait déjà sorti trois demos et un album quand l'album "Origin" d'Evanescence est sorti (album tout à fait écoutable entre nous soit dit, Sony n'avait pas encore eu le temps de faire du consensuel dessus).
AFTER FOREVER c'est ttechniquement et musicalement rès largement au dessus d'evanescence. Si tu as l'occasion de jeter uen oreille sur l'album DECIPHER je te conseille de le faire (Monolith of Doubt est un bon moyen de se faire une idée). Sinon sur le dernier album "Living Shields" et "Only Everything" sont somptueux.
Maintenant si c'est les groupes de métal à chanteuse qu te donnent des bouttons, là effectivement ca peut crisper, sinon After forever est quand même nettement plus proche de gorupes comme Epica, Sirenia, Tristania etc. que de Evanescence.
Ca n'est précisé nul part sur la jaquette du CD, et c'ets bien le problème. j'ai checké avant d'acheter (c'est devenu un reflexe) et après avoir acheté et réalisé que le CD était protégé j'ai checké une seconde fois => Rien n'est indiqué.
L'indication "Copy Protected" n'est présente que sur le CD. Il ne s'agit apparament pas de la classique protection des CD des majors (le symbole avec un triangle dans un cercle dans un triangle dans un cercle) mais un sybole qui ressemble a un bouton play (le triangle) suivi d'un bouton pause (la double barre). J'imagine que pour utiliser le logo connu il faut verser des royalties à gauche et à droite.
En parlant de matériel, wikipedia laisse entendre (à tort ou à raison ?) que tous les Intel core2 possedent Lagrande (le nom Intel pour trusted computing et TPM).
Très très malheureusement à raison. De plus les anciens portables pentium M ou autre livrée avec une sortie HDMI compatible HDTV (HD Ready) ou avec windows XP media center edition sont également équipés de La Grande par défaut.
Encore plus malheureusement La Grande (Sur lequel il est totalement impossible d'avoir d'autres docs que http://www.intel.com/technology/security/ - encore que le livre The Intel Safer Computing Initiative devrait bientôt sortir) est pour le coup tout à fait en phase avec les délires les plus paranoïaques. Au menu validation du hardware avec désactivation des fonctionnalités, ségementation mémoire en zone de confiance (en théorie pour éviter qu'un virus ne vienne corrompre votre programme, en pratique ca marche aussi très bien pour éviter que l'on lance un debugger sur un programme "certifié"). Jeu de clefs pré-certifiées pour vérifier la validité de l'éxecution/la lecture des différents fichiers (là on l'a le truc fait à 100% pour les DRM) etc.
En l'absence de docs complètes je ne peux pas vraiment le certifié mais j'ai bien l'impression que La Grande s'arrangera pour bloquer un maximum de fonctionalités pour les OS ou les programmes qui s'éloignent de la droite ligne du parti. Et comme La Grande travaille main dans la main avec les bios EFI, ca peut aller jusqu'à la désactivation complète de périphs voir le refus de booter. (Pas dès le départ hein, faut pas effrayer le chaland mais c'est en théorie tout à fait possible)
Avec un TPM - je te renvoie à notre discussion de l'été dernier. Tu semblais avoir entrevu le chemin en question dans ton dernier post:
En fait depuis les normes 1.1b et 1.2 sont devenues accessibles. Tout d'abord il y est précisé à maintes reprises que les PCR privés ne devaient jamais être révélés (ni en clair ni en signé). Apparament c'était aussi dit dans la norme 1.0 mais pas de façon suffisament claire. Là ils appuient vraiment. En plus le nombre de PCR privé est passé de 4 à 8 (1.1) puis 15 (1.1b) puis une infinité extensible pour éviter d'exploser avec l'EFI (1.2)
Cependant avec une base de données suffisante et une entente entre les différents acteurs il serait possible de prévoir ces PCR privées (celà implique quand même de garder au chaud un exemplaire de chaque configuration avec ces N Sha-1 de PCR possibles)
Avant propos : je rapelle à toutes fins utiles que la réponse que j'ai postée était suite à l'afirmation suivante : Tu vas m'expliquet comment TPM, quand l'OS lui envoie un hash pour le stocker, peut savoir qu'il s'agit du hash d'un matériel ou d'un logiciel !
afirmation dans le sens ou elle certifie que l'OS peut envoyer un hash à la puce TPM, et que celui-ci peut être matériel.
Ma réponse a cette affirmation était a) l'OS ne peut pas envoyer de hash au TPM (pour être plus précis il ne peut qu'étendre un PCR) b) La puce ne stoque pas les hashs (à l'exception des 15 premiers en norme 1.2) c) La puce n'a de toute façon pas les moyens d'accéder au matériel (excepté le bios, et encore parcequ'il est étudié pour et qu'il se charge en mémoire)
Ensuite :
Si tu stockes l'identifiant de chaque élément de la config matérielle dans un des files cité ci-dessus, alors ces identifiants seront hashés par le TPM.
Si tu as déjà un identifiant fiable de ton matériel, pourquoi ne pas l'utiliser directement ? Si il n'est pas fiable qu'est-ce qui te prouve que ce que tu envoies à la puce TPM est valable ? Si tu as déjà signé le driver (par exemple) et que celui ci te renvoit un identifiant matériel alors cette identifiant est forcément bon sans repasser par la case TPM. Et si le driver n'est pas signé/validé qu'est ce qui te prouve que l'identifiant qu'il remonte est valable ? Comme indiqué dans ta citation le TPM ne peut hasher qu'un fichier qui contient des données ou des executables chargés pendant l'execution. Une carte graphique en tant que matériel n'est pas un fichier (même sous unix - elle peut éventuellement avoir une interface qui se comporte comme un fichier mais c'est très différent) , ne contient pas d'executable (éventuellement des données - mais pas seulement) et surtout n'est pas chargée à l'execution.
Ensuite tu n'obtiendras pas la signature de l'identifiant, mais la signature de PCR, donc l'intraréévaluation de toutes les signatures précédente dans ce PCR.
Contrairement à ce que tu prétends dans de nombreux messages, ce n'est pas un hash de tous les hash qui est envoyé. Mais bien chacun des hash, donc il est possible d'identifier chaque élément séparément.
Il y a dans le papier que tu cites une introduction assez longue dans laquelle ils expliquent (rapidement) ce qui se passe. Ils décrivent notament comment ils partent du PCR[10] et comment ils le remplissent. On voit d'un coté la "measurement list" - la liste des mesures et de l'autre les hash : (page 3)
Comme tu peux le constater, avant même que l'on mesure quoi que ce soit (PCR vide, compteur à 000) on a déjà un hash de type agregate. Ce hash correspond au hash "de base" soit celui de 7 premiers PCR (on est ici en norme 1.1).
L'explication du fonctionnement est toute simple et elle est donnée à coté :
The TPM computes the new register content by building a SHA1 over the current content concatenated with the new 160bit number written into the PCR.
En plus dans ta vision des choses, le fait que les éléments soient hashés et signés en concaténation et non en stand alone est plutôt une mauvaise chose, car c'est la seule chose qui garantie que le TPM est impossible à émuler. Sinon il suffirait de prendre les mesures directement sous un OS de confiance et de les reporter à l'identique sous un OS non fiable.
Tu es plus royaliste que le roi: meme TCG avoue officiellement que la remote attestation à des fins de bloquer les utilisateurs de certaines configurations est rendue possible !
Non pas à certaines configurations, mais à tous les ordinateurs qui n'ont pas une endorsement key activée. C'est à dire à peu près tous pour l'instant je crois.
As a consequence, users who do not choose to employ TCG technology would be essentially unable to access that service.
Mais rien n'est dit au sujet de la configuration du poste, on a une EK et un TPM ou pas. Si on les a on rentre, sinon on reste à la porte.
Hors sans puce de type TPM, cette horreur est impossible !
Ah bon ? Tu connais les sites qui exigent le HTTPS ? Ceux qui te boudent si tu n'a pas flash ou le windows media player 10 (je ne parle pas ici des DRM mais bien des technos) ? Et bien c'est pareil. Tu ne veux pas suivre les prérequis, tu ne rentres pas.
Lors d'une précédente discussion, il y a 2 ou 3 ans, je t'avais donné le lien (périmé depuis) d'un document Intel sur le remote attestation qui montrait bien qu'il était prévu de pouvoir obtenir un hash indépendant pour chaque composant.
Non, il peut obtenir un hash indépendant pour chaque niveau du PCR excepté les 16 premiers (qui sont strictement interne au système pour des raisons de sécurité évidente), en demandant à envoyer un couple
{Sig(PCRA, AIKA), PCRA} . L'ennui posé ici est qu'il obtient une signature du PCRA mais aussi le PCRA en clair.
On a donc ici un moyen de récupérer morceau par morceau le fonctionnement de la machine et donc de la reconnaitre pour peu que l'on ait à disposition une base de donnée des 16 premiers PCR recouvrant toutes les configurations recensée comme valide. C'est ennorme mais pas impossible.
A noter qu'une puce qui te donnerait le hash individuel de tous les composants "de facto" ne servirait pas à grand chose, il deviendrait alors extrèmement simple de construire un clone logiciel de la puce matérielle puisque l'on aurait toutes les infos possibles (notamment le très précieux PCR0 qui une fois signé certifie que l'on a bien une puce TPM dans al machine)
Il y a déjà des banques qui imposent une carte à puce pour certains clients et certaines opérations:
La carte à puce sert d'identifiant fort. TPM est tout à fait capable de remplir ce rôle. Mais de là à identifier que ce soit avec une carte à puce ou avec une puce TPM l'OS utilisé il y a un bon bout de chemin.
Tu vas m'expliquet comment TPM, quand l'OS lui envoie un hash pour le stocker, peut savoir qu'il s'agit du hash d'un matériel ou d'un logiciel !
Alors,
a) L'OS ne peut pas envoyer de hash au TPM, ni quoi que ce soit d'ailleurs. Il ne peut que demander à étendre un PCR avec une zone mémoire (généralement, mais pas forcément la partie executable d'une application.)
b) TPM ne stoque pas les hash - exceptée les 15 premiers PCR qui sont inaccessible slogiciellement - il les rééxecute. Quand on a besoin d'accéder à une zone protégée liée à un PCR, il recalcule la valeur du PCR et voit si ca correspond. Si oui la zone est accessible, si non elle ne l'est pas.
c) le TPM ne signe pas le hardware - à l'exception de la puce elle même et du bios, laquelle siganture est d'ailleurs inaccessible - il ne signe que les zones mémoires chargées. Donc la question ne se pose de toute façon pas.
TPM ne fait que stocker les hashes que chaque élément logiciel de la trusted chain lui demande de stocker. Si l'OS ou le BIOS lui demande de stocker des hashes des identifiants matériels des cartes sons et vidéo, TPM le fera.
En norme 1.0, 1.1 et 1.2 la partie validation "physique" est statique et impossible à modifier.
Suivant les normes et les papiers celà représente les 4 ou les deux premiers stades du trusted boot.
En termes de niveau (norme 1.2) les seules choses que l'on peut signer ou non sont :
trusted OS
trusted applications
normal applications
A aucun moment il n'est question de laisser les personnes choisir quelles pièces de hardware elles veulent signer.
La puce tpm stocke les hashes de chaque composant matériel et logiciel de l'ordinateur, et peut les envoyer à un tiers avec une signature. Le tiers peut donc s'assurer que la personne avec qui il communique a exactement la configuration matérielle et logicielle qui est imposée par ce tiers.
Il s'agit de hash en cascade. On n'a donc pas directement le hash de l'OS, mais un hash cumulé. Ce qui rend l'identification nettement plus complexe.
il est à noter que si des failles exploitables à distance sont présentes dans les logiciels de votre ordinateur, et que ces failles sont utilisées pour modifier des composants de votre OS, TCPA ne peut absolument rien détécter avant le prochain boot, car c'est lors du boot que les composants des OS sont stockés.
A l'exception du bios et boot loader, les autres composants (puce TPM comprise) sont rééxaminés en boucle. La puce TPM relance une vérification d'auto validité à chaque demande effectuée et se coupe si cette vérification échoue. Lors d'une tentative d'accès à une zone protégée, l'OS et les applications concernées sont systématiquement rééxaminés.
2. Un virus/pirate malin qui ne modifie votre OS qu'en mémoire, mais pas sur votre disque dur, ne sera jamais détecté par TCPA (ni par Tripwire d'ailleurs, mais j'ai déja insisté sur le fait qu'ils étaient équivalents, sauf pour le remote attestation).
Celà dépend ou la modification s'opère, mais la zone executable de la mémoire protégée reservée à l'OS (kernel space) est systématiquement rehashée. Par contre les zones de données elles ne le sont pas, il est donc techniquement possible d'en modifier le contenu au nez et à la barbe de la TPM. Ceci étant comme la zone executable est intouchable, l'utilitée est tout de même limité.
Tu a oublié (?) de parler du "remote attestation" qui permet de refuser de communiquer avec quelqu'un s'il n'utilise pas une config matérielle et logicielle précise (par ex. windows et des cartes sons et vidéos qui n'ont pas de sortie de numérique, ce qui est pratique pour le drm).
Je n'ai pas oublié d'en parler, le problème est qu'à l'heure actuelle le remote attestation est un flop. Pour pouvoir faire du remote attestation il faut que trois conditions soient remplies :
a) - Il faut que la clef constructeur soient accessible, valide et activée. A l'heure actuelle aucune puce TPM n'en fournie une de base. IBM a arreté la construction et c'était le seul fournisseur qui "savait" mettre cette clef et la valider. (Et encore seulement sur demande)
b) - Il faut un organisme de confiance tiers pour servir d'interface. Hors il n'exise pas aujourd'hui d'organisme de ce type. En fait il n'existe même pas d'équivalent aux "root certificates" qui permetrait de trouver un tel organisme de confiance si il existait.
c) - Il faut que tout le processus de création d'un profil ait été fait par l'utilisateur, qu'il ait créé une identité au moins dans ce profil et que cette identité aient des droits de réponses étendues. Une fois de plus il n'existe pas de programme permettant de réaliser ces opérations simplement à aujourd'hui (à part sous Linux curieusement). En plus les clefs crées dans ce profil serait migrable par l'administrateur du profil vers d'autres cases, voir d'autres profils (En fait avec l'aide du mot de passe du propriétaire de la puce (mis en place lors du "take ownership") il serait même possible de migrer l'intégralité des clefs et le profil dans un autre TPM )
De plus TPM est totalement incapable de signer une carte son ou une carte graphique. Elle gère le bios, le boot loader, l'os loader, l'os et les applis qui tournent dessus. Elle est totalement incapable de savoir si la carte son existe, de là à voir si la sortie optique est activée il y a du travail.
Ceci étant il serait possible (toujours en ayant une base de données conséquente) sans même passer par la remote attestation de vérifier par challenge du hash de l'OS que l'on a bien à faire à une config connue. De là comme on à valider toutes les étapes du bios jusqu'à l'OS on peut revenir à des sécurités logicielles sans trop de risque en exigeant par exemple des pilotes et des applis signées. C'est le système "0 knowledge remote attestation"
Ceci étant vu l'essor que semble prendre "LaGrande" ce n'est pas la solution qui a été retenue. Pour être compatible HDTV et autre joyeuseté l'ajout d'un module supplémentaire, qui lui est bardé de clefs préchargées et qui lui est capable de controller le matériel (ou tout du moins de ne pas l'activer complètement), a été validée comme la solution à suivre. Seulement vu les problèmes de changement de normes et les différents accrocs qu'il y a déjà eu (MS et Sony refusent d'implémenter le système avant 2010 dans les consoles par exemple) on peut penser que le système va encore évoluer. La norme TCG 2.0 à laquelle je n'ai pas eu accès (les papiers à signer étants ridicules) jouera peut-être un rôle plus important dans la mouture finale.
Suffit juste que le binaire soit bien signé, et une signature ca demande pas de stocker tous les hash , juste UNE SEULE clé publique.
Ouhlà non, justement le TPM ne sait pas reconnaitre un binaire signé. Pas du tout même. Ensuite il est strictement interdit par la norme (pour l'instant jusqu'en 1.2) de stoquer des clefs à priori dans la machine.
Le TPM peut :
-Hasher une séquence de lancement, du bios jusqu'à l'appli (mais il ne peut pas hasher l'appli seule)
- En fonction de l'analyse d'une séquence de lancement donner accès ou non à des "cases" mémoires ou se trouvent les clefs.
- Répondre à un challenge sur une clef contenue dans une case ouverte (et ainsi valider une de ses signature ou décrypter un message)
Le TPM ne peut pas (d'après les docs auquelles j'ai eu accès)
- Certifier qu'un binaire a bien été signé par une tierce partie. En effet les seuls signatures qu'un TPM peut valider sont celles qu'il a créé lui même. Il est impossible de "faire rentrer" une clef publique ou une clef privée dans un TPM, on peut juste lui demander d'en générer une nouvelle - qui restera toujours cachée à l'intérieur du TPM (sauf en cas de migration).
- Bloquer l'execution d'un programme. Le TPM est comparable à une boite noire posée à l'arrière d'un port série. Il n'a en aucune manière le pouvoir de changer le fonctionnement de l'ordinateur, il ne peut qu'interdire l'accès aux clefs qu'il contient.
- être préconfiguré par les marchands de logiciels et/ou de matériel à l'avance. Là c'est juste la norme qui l'interdit, ca pourrait changer et c'ets techniquement réalisable, mais il est pour l'instant exclu que l'on puisse vendre un TPM avec des cases préparamétrées à l'avance et déjà réglées sur "Boot certifé de windows" par exemple.
Donc avec juste une clef publique on ne fait pas grand chose. Maintenant vu ce que j'ai entre-aperçu de "La Grande" il y a dans le système Intel un module supplémentaire qui est a) préparamétré et b) capable de valider la présence de matériel et/ou de logiciel compatible avec la ligne du parti...
binaire : un système permet d'identifier les programmes (et documents) qui sont sur votre ordinateur. mais ici vous n'avez pas le choix d'identifier par vous même les binaires dans lesquels vous avez confiance.
Il est possible pour les constructeurs de brider des fonctionnalités de leur matériel en fonction de la séquence de boot, mais celà demande une base de données assez conséquente.
La façon dont TCPA fonctionne ne permet pas de signer un élément à part. Il y a un enchainement de hash qui donne le résultat final, c'est d'ailleurs le but. A quoi servirait d'avoir un boot sector valide si le bios a été corrompu ? De même à quoi sert de vérifier l'OS sans vérifier d'abord le boot sector (l'OS peut tourner dans une machine virtuelle après tout). Donc la norme TCPA ne permet pas de signer 'juste' un binaire. La séquence de chiffrement lors de la demande de signature d'une application est proche de celle-ci :
hash(puce)
hash(bios + hash(puce))
hash(os loader +hash(bios + hash(puce)))
hash(OS + hash(os loader +hash(bios + hash(puce))))
hash(applis + hash(OS + hash(os loader +hash(bios + hash(puce)))))
En d'autres termes la signature lorsque l'on demande le hash d'une application change dès que l'on touche à quoi que ce soit qui se trouve en dessous de l'appli. Difficile donc de certifier que l'appli est bonne a moins d'avoir une base de données sur les différents éléments possibles absolument gigansteque et de la suivre au gré des différentes mise à jour (bios et windows update notamment)
Si l'on veut faire du DRM avec TCPA on est obligé de s'arreter au niveau inférieur (hash de l'OS) et de travailler main dans la main avec le fabriquant de l'OS pour suivre les évolutions des hash. Derrière il faut que l'OS dispose lui d'un moyen de se certifier "tout seul" - ce qui est faisable mais descend la sécurité à un niveau plus bas - et de remonter cette certification via la TPM.
De plus normalement les puces TPM ne peuvent pas être livrées pré-certifiées (la norme l'interdit spécifiquement, et celà limiterait ennormément leur usage), et qu'il faut donc que l'utilisateur a) active la puce t b) la remplisse lui même au moins au début - a noter cependant que ca n'est pas techniquement impossible, et que il se peut très bien que les constructeurs changent d'avis. Mais il est plus probable qu'ils utilisent un système supplémentaire basé sur TPM mais qui possède des fonctions et des mémoires séparées pour faciliter la validation/activation du hardware et du software morceau par morceau (c'est le système LaGrande d'Intel, et c'ets de loin celui qui me fait le plus peur).
[^] # Re: ouais
Posté par Jerome Herman . En réponse au journal printf debugging considered harmful. Évalué à 6.
Les rares fois ou j'ai debugé du multithreadé avec des printf sur la sortie standard, j'étais bien content de ne pas maitriser l'ordre d'affichage. En fait c'était même un peut le but. C'est là qu'on arrivait à de jolis use-case avec un affichage qui permettait de savori quel thread avait fait quoi avant/après tel autre thread.
Le gros défaut de la sortie standard c'est qu'ecrire dessus c'est non atomique, il peut donc se passer des choses entre le début et la fin de l'écriture (interrupt, segfault d'un autre thread qui plie le process etc.)
Gros problème pour faire du debug avec exclusivement des commandes atomiques il faut se lever de bonne heure (que ce soit avec printf, GDB ou des buffers extérieurs).
On peut tricher avec un process extérieur et des IPC mais généralement on obtient des résultats assez variables.
L'idéal c'est un simulateur qu'on peut mettre en pause, retour arrière, avance rapide quand on veut. Mais là il vaut mieux avoir de la ram et de la puissance CPU à disposition, parceque ca risque de ramer (surtout si vous avez des dizaines et des dizaines de threads).
Pour finir il est important de bien se rendre compte d'un chose : il ets impossible d'écrire un debuggueur parfait. Etre capable d'écrire un programme qui va trouver toutes les failles dans n'importe quel code est équivalent à écrire un programme capable de detecter si n'importe quel code va se terminer. Pour debugguer rien en remplace donc le cerveau. Certaines méthodes vont marcher, d'autres pas du tout mais il est assez difficile de savoir à priori lesquelles.
# Of GDB considered Harmful
Posté par Jerome Herman . En réponse au journal printf debugging considered harmful. Évalué à 10.
Restons clair, si GDB est un excellent outil pour former les programmeurs débutants à la notion de pointeur et de libération de mémoire, il ne devrait jamais être utilisé pour quoi que ce soit d'autre. Donc passé deux ans à faire du C de façon intensive jetez le aux oubliettes et utilisez des appels intracode pour vous informer des problèmes rencontrés (printf est une bonne solution dans 90% des cas)
Les inconvennients majeurs de GDB :
- Un programme C/C++ compilé en mode "debug" ne se comporte pas (parfois pas du tout) comme le même programme compilé en mode standard. les différences principales sont :
* différence dans le link des bibliothèques. Le simple fait d'activer GDB dans un programme qui lie une bibliothèque compilée sans les options de debug peut faire apparaitre/disparaitre pas mal de bugs.
* différence dans la signature des pointeurs de fonctions. Si vous avez le moindre paramêtre système dans votre fonction, il y a 9 chances sur 10 pour que sa signature change après un passage de GDB. Cela peut également faire apparaitre/disparaitre un paquet de bugs. (des segfault souvent)
* remontée de tout un tas d'appels systèmes pour suivre le déroulement du programme qui n'existent pas dans les versions compilées en standard.
- Dans la plupart des programmes, GDB ne peut pas grand chose pour vous :
* Oubliez le mot clef "volatile" à moins de s'en servir exclusivement pour GDB. (Bon vous allez me dire que de toute façon vous ne connaissiez pas le keyword volatile)
* Oubliez les interruptions systèmes, notamment alarm, gettime et sleep. Certains messages passent, d'autres sont trappés par GDB directemetn sans jamais atteindre votre programme.
* GDB est totalement inutile en cas de programmation concurrente/parallèle. Il ne comprend rien au fichiers mappés en mémoire par un autre process et a du mal avec les messages IPC/ITC (com entre processes, com entre threads) un peu complexe.
* Si pour une raison quelconque, la mémoire allouée par un process est désallouée par un autre, c'est festival.
* Pour les raisons évoquée plus haut n'essayez même pas d'utiliser GDB en dehors du userland, vous allez vous faire mal à le kernel.
- GDB vous empêche de comprendre ce qui se passe vraiment.
* GDB ne comprend pas le code, il le trace. Si vous avez fait une erreur conceptuelle quelque part, GDB vous maintiendra dans l'illusion quand allouant un octet mémoire de plus ou en castant un peu plus violamment une variable ca marche.
* GDB ne comprend pas ce que vous cherchez à faire. A moins de truffer le code de volatile dédiés, GDB va vous aider à debugger les différents cas de figures un par un. A moins d'être très propre, très rigoureux et pas pressé par le temps, votre code (si il est imposant) ressemblera rapidement un un patchwork de verrues et de pansements. On reconnait le code des afficionados de GDB aux nombres de tests qu'il y a dans le code.
* GDB check, trace et valide le code. Il est totalement insensible au système et à l'environnement de la machine. Si votre programme plante suite à un appel système, GDB vous permettra de trouver ou dans le code il faut contourner l'appel système. Mais il ne sera d'aucune utilité sur le pourquoi, le comment et la méthode à adopter pour traiter/ignorer l'appel système.
En bref GDB c'est bien pour les petites applis monotache, mono-utilisateur, monoprocess qui n'ont pas besoin des fonctions systèmes ou d'appels complexes à des bibliothèques extérieures.
Pour le reste, utilisez votre cerveau.
[^] # Re: Gentoo, franchement non
Posté par Jerome Herman . En réponse au journal Le magicien, La vache et le Canard Pimpant.... Évalué à 3.
Revient ici malheureux !
A moins que tu veuilles jouer avec les slots sur toutes tes libs dès qu'il y a du C++ dans l'air je te conseille de patienter un peu avant de te jeter sur GCC 4.x
Ensuite, par défaut GCC 4.x est présent mais ne sert pas à grand chose, il est juste mis dans un slot à coté et c'ets toujours le 3 qui fait le boulot de compil.
Pour finir je te conseille vivement de quickpackager (le premier qui me dit qu'en francais ils faut dire prestempaqueter gagne un cadeau surprise) deux trois trucs avant de te lancer dans les compils. parmis lesquels (dans l'ordre d'importance) : la libstdc++, Xorg-x11, gcc 3.x et KDE si besoin
Après je te laisse le bonheur de te rendre compte qu'il y a quand même pas mal de trucs qui compilent assez moyennement avec GCC4
[^] # Re: marque
Posté par Jerome Herman . En réponse au journal DVD et lecteurs de salons. Évalué à 2.
Ces .vob devraient s'ouvrir et être lus par VLC (si le fichier est protégé CSS ca fera de gros blocs verts, mais au moins on saura que les données sont accessibles.)
# Peut-être hors sujet mais...
Posté par Jerome Herman . En réponse au journal DVD et lecteurs de salons. Évalué à 10.
La qualité du graveur par exemple influe beaucoup sur le résultat, le support aussi. Si vous voulez obtenir des DVD lisible facilement sur autre chose que la plateforme de gravure, voici rapidement les recommandations que l'on peut faire :
a) évitez les DVD+R\RW. Les DVD+ sont beaucoup plus compelxes à lire que les DVD- . De fait on peut faire nettement plus de choses avec (multi-mode, gravure depuis un point arbitraire, multisession détaché etc.) MAIS de part cette complexité pas mal de lecteurs même sois-disant compatible DVD+ se prennent les pieds dans les différents catalogues et les métadonnées.
(Par contre les DVD+ c'ets le top pour sauvegarder des données destinées à être lues exclusivemetn sur ordi)
b) Si possible limiter la vitesse de gravure. Graver un DVD en 8x est rarement une bonne idée. Lors de la gravure un DVD va déjà générer des erreurs en pagaille (toutes corrigées par les différents CRC si la gravure s'est bien terminée) , ca n'est pas la peine de prendre plus de risque en poussant le lecteur au maximum. La vitesse qui marchent très bien sur mon plextor sous Linux c'est 1,43x (le minimum). Si je passe à 2 ou 4x mon DVD reste lisible mais les erreurs correctibles se multiplient.
c) Prenez un support de bonne qualité. Les DVD gravables noname ont les mêmes inconvennients que la gravure à grande vitesse : multiplication des erreurs de gravure. Personnellement je recommande les DVD de marque Verbatim ou Fujifilm pour les produits finis destinés à être distribués, ils passent bien avec à peu près tous les graveurs que j'ai essayé. Si ca fait trop mal au porte-monnaie, j'ai aussi obtenu de bons résultats avec les TDK, mais c'était il y a un moment.
En fait il faut essayer de mettre la main sur des disques fabriquées par Tayo yunden ou à défaut par Mitsubishi Chemicals. Le site cdfreaks.com est un bon moyen de comparer les résultats et de choisir une marque de référence soi-même.
d) Pas de multi-sessions. Les DVD-R sont nuls en multi-session. Si vous voulez faire du multi-session prenez des DVD+, mais comme dit dans le a) ils sont plus complexes à lire et donc on prend le risque d'avoir des DVD lisibles sur un nombr eplus limité de plateformes.
e) Si possible faites la finalisation du disque sur l'ordi plutôt que sur la platine. Certaines platines ont uen façon assez spéciale de refermer le catalogue (probablement pour ajouter pleins de fonctionnalités rigolotes utilisable seulement par la platine elle-même). Tant pis pour les fonctionnalités non standard.
Normalement en respectant ces consignes on arrive à faire des DVD relativement bien compatibles avec la plupart des platines.
# Un mouvement logique et parfaitement dans la lignée commerciale
Posté par Jerome Herman . En réponse au journal Microsoft veut coopérer avec l'équipe Mozilla pour le dev de firefox. Évalué à 10.
Or là on vient de leur donner sur un plateau, avec le renforcement du DMCA aux US et l'application des lois sur la sécurité numérique en Europe, un monopole sur la lecture des médias nouvelle génération. Entre les lecteurs Matsushita/panasonic qui refusent les accès RAW aux DVD de la mauvaise zone et l'impossibilité de lire les HDVD/BLU-Ray sur une plateforme ouverte ils sont aux anges.
De fait la possiblité que les particuliers quittent Windows pour Linux dans les 5 années à venir se réduit comme peau de chagrin. Une fois fini les bouteilles de champagnes il est normal que les pontes de Microsoft se demandent comment retirer les deux ou trois derniers atours du libre. S'assurer que Thunderbird et Firefox tournent sous Vista est une bonne solution. Je epnse qu'ils vont même tout faire pour que Firefox et Thunderbird aient sous Vista de chouettes fonctionnalités qui n'existeront pas sous Linux avant quelques années et hop c'est dans la poche.
Bien sur c'est mon opinion personelle, mais ce mouvement ne me surprend pas outre mesure. Rien de nouveau sous le soleil, "embrace and extend" comme ils disent.
[^] # Re: Et le kung-fu ?
Posté par Jerome Herman . En réponse au journal Ju-jitsu ou karaté. Évalué à 3.
C'est un art assez sympa à apprendre, surtout si le temple/gymnase ou tu l'apprends enseigne aussi le maniement des armes en parallèle. Le truc c'est que le Wushu est assez pénible si on tombe sur un maitre rigoureux. Il vaut mieux avoir une assez bonne condition physique et pas mal de souplesse au moment ou on commence sinon on peut avoir vraiment du mal à finir une séance (personellement j'avais les muscles lombaires trop faible et la première fois j'ai même pas pu finir l'échauffement tellement j'avais mal).
Au niveau combat le Wushu est probablement l'art qui tient le mieux sa position entre équilibre et force. A savoir que l'on tappe comme des bourrins façon Karate tout en gardant un bon équilibre sur ses pieds façon aikido/judo.
J'aime beaucoup cet art, mais il faut reconnaitre qu'il a deux défauts : le premier est qu'il doit normalement s'accompagner de longues phases de reflexion et de méditation, et qui en 2x2h par semaine est pas évident, on s'éloigne donc forcément de l'esprit des maitres (sauf à aller dans un temple Shaolin, mais c'est pas donné à tout le monde). Le deuxième c'est que le Wushu vise à faire naitre des reflexes assez brutaux quand on est en situation de combat. On s'entrainne pour celà à répeter les mêmes enchainements sur des PAO pendant des cours entiers. Mais le problème est qu'en situation d'agression, l'enchainement peut parfois sortir "tout seul", ce qui est généralement une très mauvaise idée. Ca vient peut être du maitre que j'ai eu, mais je pense qu'il manque une partie du self control que l'on peut aquérir dans les arts japonais, et comme le Wushu est assez destructeur...
Ceci dit, c'est très très sympa, notamment au niveau de ce que l'on arrive à faire après un ou deux ans de pratique régulière.
[^] # Re: hehe
Posté par Jerome Herman . En réponse au journal Petite question. Évalué à 6.
Encore très très rare. A ma connaissance seul certains lecteurs de chez panasonic/matshita sont capable de refuser l'accès raw (et encore seulement sur les zones qu'ils considèrent comme invalides). Sinon tous les autres lecteurs ou presque fonctionnent très bien en accès raw (c'est d'ailleurs ce qui a fait le succès de DeCSS). La copie raw marche dans 99% des cas.
[^] # Re: Et tiens nous au courant
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 5.
En 3 minutes l'affaire était pliée et le bon d'achat dans ma poche (j'imagine qu'un remboursement en liquide ou en retour sur ma CB aurait été plus problématique, mais je suis peut être mauvaise langue)
Donc voilà un CD déballé qui va faire tache sur la liste des produits.
[^] # Re: Merci bien
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 4.
A part l'album "Enter" (très bon, mais pas super bien produit), Within Temptation ca ne joue pas vraiment dans la même cour. Les mélodies sont nettement plus simple (plus pop diraientt les détracteurs) et Sharon a quand même pas mal calmé le jeu sur sa voix (qui reste très belle, mais nettement moins puissante qu'elle n'avait pu l'être).
Et puis depuis l'album Silent Force on sent un revirement très net vers le POP/Nu-Metal (déjà un poil ammorcé avec la reprise de Kate Bush - "runing up that hill"). Donc mettre Within Temptation et Evanescence dans le même sac ca n'est pas à proprement parlé abbhérant.
[^] # Re: Merci bien
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 4.
Si tu fais allusion à la pochette de remagine, effectivement c'est pas terrible. Ceci étant Floor Jansen ne rentre pas vraiment dans la catégorie des "poufiasses". Son imposante stature, sa voix et ses yeux la protègent ad vitam eternam de ce status.
[^] # Re: Et tiens nous au courant
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 5.
Et non, tromperie sur la marchandise, défaut d'information, matériel deffectueux tout ça. C'est vendu au stand des CD, au millieu des CD et ca n'en est pas un. La loi protège le consomatuer de ce genre de cas.
D'ailleurs, si tu regarde bien, il me semble que la plupart des "cds" copy controlled n'ont plus le logo CD.
Normalement aucun, généralement pour protégé un CD on est obligé de sortir des normes assez strictes du livre blanc de Phillips.
Et donc on perd le droit à l'appelation Compact Disc (tout court).
[^] # Re: Merci bien
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 4.
Euh... Tu as pas du écouter plus de trente secondes d'AFTER FOREVER dans ta vie, et encore probablement "Being Everyone" sur l'album Reimagine, parceque sinon...
After Forever avait déjà sorti trois demos et un album quand l'album "Origin" d'Evanescence est sorti (album tout à fait écoutable entre nous soit dit, Sony n'avait pas encore eu le temps de faire du consensuel dessus).
AFTER FOREVER c'est ttechniquement et musicalement rès largement au dessus d'evanescence. Si tu as l'occasion de jeter uen oreille sur l'album DECIPHER je te conseille de le faire (Monolith of Doubt est un bon moyen de se faire une idée). Sinon sur le dernier album "Living Shields" et "Only Everything" sont somptueux.
Maintenant si c'est les groupes de métal à chanteuse qu te donnent des bouttons, là effectivement ca peut crisper, sinon After forever est quand même nettement plus proche de gorupes comme Epica, Sirenia, Tristania etc. que de Evanescence.
[^] # Re: Et tiens nous au courant
Posté par Jerome Herman . En réponse au journal Amateur de Metal : Attention piège à cons. Évalué à 9.
L'indication "Copy Protected" n'est présente que sur le CD. Il ne s'agit apparament pas de la classique protection des CD des majors (le symbole avec un triangle dans un cercle dans un triangle dans un cercle) mais un sybole qui ressemble a un bouton play (le triangle) suivi d'un bouton pause (la double barre). J'imagine que pour utiliser le logo connu il faut verser des royalties à gauche et à droite.
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 5.
Très très malheureusement à raison. De plus les anciens portables pentium M ou autre livrée avec une sortie HDMI compatible HDTV (HD Ready) ou avec windows XP media center edition sont également équipés de La Grande par défaut.
Encore plus malheureusement La Grande (Sur lequel il est totalement impossible d'avoir d'autres docs que http://www.intel.com/technology/security/ - encore que le livre The Intel Safer Computing Initiative devrait bientôt sortir) est pour le coup tout à fait en phase avec les délires les plus paranoïaques. Au menu validation du hardware avec désactivation des fonctionnalités, ségementation mémoire en zone de confiance (en théorie pour éviter qu'un virus ne vienne corrompre votre programme, en pratique ca marche aussi très bien pour éviter que l'on lance un debugger sur un programme "certifié"). Jeu de clefs pré-certifiées pour vérifier la validité de l'éxecution/la lecture des différents fichiers (là on l'a le truc fait à 100% pour les DRM) etc.
En l'absence de docs complètes je ne peux pas vraiment le certifié mais j'ai bien l'impression que La Grande s'arrangera pour bloquer un maximum de fonctionalités pour les OS ou les programmes qui s'éloignent de la droite ligne du parti. Et comme La Grande travaille main dans la main avec les bios EFI, ca peut aller jusqu'à la désactivation complète de périphs voir le refus de booter. (Pas dès le départ hein, faut pas effrayer le chaland mais c'est en théorie tout à fait possible)
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 2.
En fait depuis les normes 1.1b et 1.2 sont devenues accessibles. Tout d'abord il y est précisé à maintes reprises que les PCR privés ne devaient jamais être révélés (ni en clair ni en signé). Apparament c'était aussi dit dans la norme 1.0 mais pas de façon suffisament claire. Là ils appuient vraiment. En plus le nombre de PCR privé est passé de 4 à 8 (1.1) puis 15 (1.1b) puis une infinité extensible pour éviter d'exploser avec l'EFI (1.2)
Cependant avec une base de données suffisante et une entente entre les différents acteurs il serait possible de prévoir ces PCR privées (celà implique quand même de garder au chaud un exemplaire de chaque configuration avec ces N Sha-1 de PCR possibles)
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 6.
Tu vas m'expliquet comment TPM, quand l'OS lui envoie un hash pour le stocker, peut savoir qu'il s'agit du hash d'un matériel ou d'un logiciel !
afirmation dans le sens ou elle certifie que l'OS peut envoyer un hash à la puce TPM, et que celui-ci peut être matériel.
Ma réponse a cette affirmation était a) l'OS ne peut pas envoyer de hash au TPM (pour être plus précis il ne peut qu'étendre un PCR) b) La puce ne stoque pas les hashs (à l'exception des 15 premiers en norme 1.2) c) La puce n'a de toute façon pas les moyens d'accéder au matériel (excepté le bios, et encore parcequ'il est étudié pour et qu'il se charge en mémoire)
Ensuite :
Si tu stockes l'identifiant de chaque élément de la config matérielle dans un des files cité ci-dessus, alors ces identifiants seront hashés par le TPM.
Si tu as déjà un identifiant fiable de ton matériel, pourquoi ne pas l'utiliser directement ? Si il n'est pas fiable qu'est-ce qui te prouve que ce que tu envoies à la puce TPM est valable ? Si tu as déjà signé le driver (par exemple) et que celui ci te renvoit un identifiant matériel alors cette identifiant est forcément bon sans repasser par la case TPM. Et si le driver n'est pas signé/validé qu'est ce qui te prouve que l'identifiant qu'il remonte est valable ? Comme indiqué dans ta citation le TPM ne peut hasher qu'un fichier qui contient des données ou des executables chargés pendant l'execution. Une carte graphique en tant que matériel n'est pas un fichier (même sous unix - elle peut éventuellement avoir une interface qui se comporte comme un fichier mais c'est très différent) , ne contient pas d'executable (éventuellement des données - mais pas seulement) et surtout n'est pas chargée à l'execution.
Ensuite tu n'obtiendras pas la signature de l'identifiant, mais la signature de PCR, donc l'intraréévaluation de toutes les signatures précédente dans ce PCR.
Contrairement à ce que tu prétends dans de nombreux messages, ce n'est pas un hash de tous les hash qui est envoyé. Mais bien chacun des hash, donc il est possible d'identifier chaque élément séparément.
Il y a dans le papier que tu cites une introduction assez longue dans laquelle ils expliquent (rapidement) ce qui se passe. Ils décrivent notament comment ils partent du PCR[10] et comment ils le remplissent. On voit d'un coté la "measurement list" - la liste des mesures et de l'autre les hash : (page 3)
000:D6DC…D3DB n/a [boot aggregate]
001:84AB…DA4F [exec]
init
002:9ECF…BE3D [library]
ld-2.3.2.so
003:3365…2342 [library]
libc-2.3.2.so
004:A4DC…C12B [exec]
bash
…
027:2AC8…980D [bash-src]
clock
028:C0F7…9A3D [exec]
hwclock
…
070:01B3…9A1E [bash-cmd]
rc
071:CEBA…1AA4 [exec]
runlevel
072:2998…8ED4 [bash-cmd]
egrep
073:6846…B72D [bash-cmd]
kudzu
…
080:147D…8168 [module]
parport
081:F940…0115 [module]
parport_pc
…
244:D312…DA7C [bash-cmd]
rc.local
245:BB2C…AAB3 [exec]
mingetty
Comme tu peux le constater, avant même que l'on mesure quoi que ce soit (PCR vide, compteur à 000) on a déjà un hash de type agregate. Ce hash correspond au hash "de base" soit celui de 7 premiers PCR (on est ici en norme 1.1).
L'explication du fonctionnement est toute simple et elle est donnée à coté :
En plus dans ta vision des choses, le fait que les éléments soient hashés et signés en concaténation et non en stand alone est plutôt une mauvaise chose, car c'est la seule chose qui garantie que le TPM est impossible à émuler. Sinon il suffirait de prendre les mesures directement sous un OS de confiance et de les reporter à l'identique sous un OS non fiable.
Tu es plus royaliste que le roi: meme TCG avoue officiellement que la remote attestation à des fins de bloquer les utilisateurs de certaines configurations est rendue possible !
Non pas à certaines configurations, mais à tous les ordinateurs qui n'ont pas une endorsement key activée. C'est à dire à peu près tous pour l'instant je crois.
Mais rien n'est dit au sujet de la configuration du poste, on a une EK et un TPM ou pas. Si on les a on rentre, sinon on reste à la porte.
Hors sans puce de type TPM, cette horreur est impossible !
Ah bon ? Tu connais les sites qui exigent le HTTPS ? Ceux qui te boudent si tu n'a pas flash ou le windows media player 10 (je ne parle pas ici des DRM mais bien des technos) ? Et bien c'est pareil. Tu ne veux pas suivre les prérequis, tu ne rentres pas.
[^] # Re: le "remote attestation" (mouchard) est la seule nouveauté de tcpa
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 1.
Non, il peut obtenir un hash indépendant pour chaque niveau du PCR excepté les 16 premiers (qui sont strictement interne au système pour des raisons de sécurité évidente), en demandant à envoyer un couple
{Sig(PCRA, AIKA), PCRA} . L'ennui posé ici est qu'il obtient une signature du PCRA mais aussi le PCRA en clair.
On a donc ici un moyen de récupérer morceau par morceau le fonctionnement de la machine et donc de la reconnaitre pour peu que l'on ait à disposition une base de donnée des 16 premiers PCR recouvrant toutes les configurations recensée comme valide. C'est ennorme mais pas impossible.
A noter qu'une puce qui te donnerait le hash individuel de tous les composants "de facto" ne servirait pas à grand chose, il deviendrait alors extrèmement simple de construire un clone logiciel de la puce matérielle puisque l'on aurait toutes les infos possibles (notamment le très précieux PCR0 qui une fois signé certifie que l'on a bien une puce TPM dans al machine)
[^] # Re: Les TPM sont dangeureux, remote attestation
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 3.
La carte à puce sert d'identifiant fort. TPM est tout à fait capable de remplir ce rôle. Mais de là à identifier que ce soit avec une carte à puce ou avec une puce TPM l'OS utilisé il y a un bon bout de chemin.
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 3.
Alors,
a) L'OS ne peut pas envoyer de hash au TPM, ni quoi que ce soit d'ailleurs. Il ne peut que demander à étendre un PCR avec une zone mémoire (généralement, mais pas forcément la partie executable d'une application.)
b) TPM ne stoque pas les hash - exceptée les 15 premiers PCR qui sont inaccessible slogiciellement - il les rééxecute. Quand on a besoin d'accéder à une zone protégée liée à un PCR, il recalcule la valeur du PCR et voit si ca correspond. Si oui la zone est accessible, si non elle ne l'est pas.
c) le TPM ne signe pas le hardware - à l'exception de la puce elle même et du bios, laquelle siganture est d'ailleurs inaccessible - il ne signe que les zones mémoires chargées. Donc la question ne se pose de toute façon pas.
d) Je n'ai rien à expliqueT
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 4.
En norme 1.0, 1.1 et 1.2 la partie validation "physique" est statique et impossible à modifier.
Suivant les normes et les papiers celà représente les 4 ou les deux premiers stades du trusted boot.
En termes de niveau (norme 1.2) les seules choses que l'on peut signer ou non sont :
trusted OS
trusted applications
normal applications
A aucun moment il n'est question de laisser les personnes choisir quelles pièces de hardware elles veulent signer.
[^] # Re: le "remote attestation" (mouchard) est la seule nouveauté de tcpa
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 1.
Il s'agit de hash en cascade. On n'a donc pas directement le hash de l'OS, mais un hash cumulé. Ce qui rend l'identification nettement plus complexe.
il est à noter que si des failles exploitables à distance sont présentes dans les logiciels de votre ordinateur, et que ces failles sont utilisées pour modifier des composants de votre OS, TCPA ne peut absolument rien détécter avant le prochain boot, car c'est lors du boot que les composants des OS sont stockés.
A l'exception du bios et boot loader, les autres composants (puce TPM comprise) sont rééxaminés en boucle. La puce TPM relance une vérification d'auto validité à chaque demande effectuée et se coupe si cette vérification échoue. Lors d'une tentative d'accès à une zone protégée, l'OS et les applications concernées sont systématiquement rééxaminés.
2. Un virus/pirate malin qui ne modifie votre OS qu'en mémoire, mais pas sur votre disque dur, ne sera jamais détecté par TCPA (ni par Tripwire d'ailleurs, mais j'ai déja insisté sur le fait qu'ils étaient équivalents, sauf pour le remote attestation).
Celà dépend ou la modification s'opère, mais la zone executable de la mémoire protégée reservée à l'OS (kernel space) est systématiquement rehashée. Par contre les zones de données elles ne le sont pas, il est donc techniquement possible d'en modifier le contenu au nez et à la barbe de la TPM. Ceci étant comme la zone executable est intouchable, l'utilitée est tout de même limité.
[^] # Re: Trusted computing = remote attestation= windows drm obligatoire
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 6.
Je n'ai pas oublié d'en parler, le problème est qu'à l'heure actuelle le remote attestation est un flop. Pour pouvoir faire du remote attestation il faut que trois conditions soient remplies :
a) - Il faut que la clef constructeur soient accessible, valide et activée. A l'heure actuelle aucune puce TPM n'en fournie une de base. IBM a arreté la construction et c'était le seul fournisseur qui "savait" mettre cette clef et la valider. (Et encore seulement sur demande)
b) - Il faut un organisme de confiance tiers pour servir d'interface. Hors il n'exise pas aujourd'hui d'organisme de ce type. En fait il n'existe même pas d'équivalent aux "root certificates" qui permetrait de trouver un tel organisme de confiance si il existait.
c) - Il faut que tout le processus de création d'un profil ait été fait par l'utilisateur, qu'il ait créé une identité au moins dans ce profil et que cette identité aient des droits de réponses étendues. Une fois de plus il n'existe pas de programme permettant de réaliser ces opérations simplement à aujourd'hui (à part sous Linux curieusement). En plus les clefs crées dans ce profil serait migrable par l'administrateur du profil vers d'autres cases, voir d'autres profils (En fait avec l'aide du mot de passe du propriétaire de la puce (mis en place lors du "take ownership") il serait même possible de migrer l'intégralité des clefs et le profil dans un autre TPM )
De plus TPM est totalement incapable de signer une carte son ou une carte graphique. Elle gère le bios, le boot loader, l'os loader, l'os et les applis qui tournent dessus. Elle est totalement incapable de savoir si la carte son existe, de là à voir si la sortie optique est activée il y a du travail.
Ceci étant il serait possible (toujours en ayant une base de données conséquente) sans même passer par la remote attestation de vérifier par challenge du hash de l'OS que l'on a bien à faire à une config connue. De là comme on à valider toutes les étapes du bios jusqu'à l'OS on peut revenir à des sécurités logicielles sans trop de risque en exigeant par exemple des pilotes et des applis signées. C'est le système "0 knowledge remote attestation"
Ceci étant vu l'essor que semble prendre "LaGrande" ce n'est pas la solution qui a été retenue. Pour être compatible HDTV et autre joyeuseté l'ajout d'un module supplémentaire, qui lui est bardé de clefs préchargées et qui lui est capable de controller le matériel (ou tout du moins de ne pas l'activer complètement), a été validée comme la solution à suivre. Seulement vu les problèmes de changement de normes et les différents accrocs qu'il y a déjà eu (MS et Sony refusent d'implémenter le système avant 2010 dans les consoles par exemple) on peut penser que le système va encore évoluer. La norme TCG 2.0 à laquelle je n'ai pas eu accès (les papiers à signer étants ridicules) jouera peut-être un rôle plus important dans la mouture finale.
[^] # Re: Les TPM sont dangeureux mais peuvent être utiles
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 5.
Ouhlà non, justement le TPM ne sait pas reconnaitre un binaire signé. Pas du tout même. Ensuite il est strictement interdit par la norme (pour l'instant jusqu'en 1.2) de stoquer des clefs à priori dans la machine.
Le TPM peut :
-Hasher une séquence de lancement, du bios jusqu'à l'appli (mais il ne peut pas hasher l'appli seule)
- En fonction de l'analyse d'une séquence de lancement donner accès ou non à des "cases" mémoires ou se trouvent les clefs.
- Répondre à un challenge sur une clef contenue dans une case ouverte (et ainsi valider une de ses signature ou décrypter un message)
Le TPM ne peut pas (d'après les docs auquelles j'ai eu accès)
- Certifier qu'un binaire a bien été signé par une tierce partie. En effet les seuls signatures qu'un TPM peut valider sont celles qu'il a créé lui même. Il est impossible de "faire rentrer" une clef publique ou une clef privée dans un TPM, on peut juste lui demander d'en générer une nouvelle - qui restera toujours cachée à l'intérieur du TPM (sauf en cas de migration).
- Bloquer l'execution d'un programme. Le TPM est comparable à une boite noire posée à l'arrière d'un port série. Il n'a en aucune manière le pouvoir de changer le fonctionnement de l'ordinateur, il ne peut qu'interdire l'accès aux clefs qu'il contient.
- être préconfiguré par les marchands de logiciels et/ou de matériel à l'avance. Là c'est juste la norme qui l'interdit, ca pourrait changer et c'ets techniquement réalisable, mais il est pour l'instant exclu que l'on puisse vendre un TPM avec des cases préparamétrées à l'avance et déjà réglées sur "Boot certifé de windows" par exemple.
Donc avec juste une clef publique on ne fait pas grand chose. Maintenant vu ce que j'ai entre-aperçu de "La Grande" il y a dans le système Intel un module supplémentaire qui est a) préparamétré et b) capable de valider la présence de matériel et/ou de logiciel compatible avec la ligne du parti...
[^] # Re: Trusted computing = free software
Posté par Jerome Herman . En réponse à la dépêche TCPA/TPM : la déferlante silencieuse. Évalué à 10.
Il est possible pour les constructeurs de brider des fonctionnalités de leur matériel en fonction de la séquence de boot, mais celà demande une base de données assez conséquente.
La façon dont TCPA fonctionne ne permet pas de signer un élément à part. Il y a un enchainement de hash qui donne le résultat final, c'est d'ailleurs le but. A quoi servirait d'avoir un boot sector valide si le bios a été corrompu ? De même à quoi sert de vérifier l'OS sans vérifier d'abord le boot sector (l'OS peut tourner dans une machine virtuelle après tout). Donc la norme TCPA ne permet pas de signer 'juste' un binaire. La séquence de chiffrement lors de la demande de signature d'une application est proche de celle-ci :
hash(puce)
hash(bios + hash(puce))
hash(os loader +hash(bios + hash(puce)))
hash(OS + hash(os loader +hash(bios + hash(puce))))
hash(applis + hash(OS + hash(os loader +hash(bios + hash(puce)))))
En d'autres termes la signature lorsque l'on demande le hash d'une application change dès que l'on touche à quoi que ce soit qui se trouve en dessous de l'appli. Difficile donc de certifier que l'appli est bonne a moins d'avoir une base de données sur les différents éléments possibles absolument gigansteque et de la suivre au gré des différentes mise à jour (bios et windows update notamment)
Si l'on veut faire du DRM avec TCPA on est obligé de s'arreter au niveau inférieur (hash de l'OS) et de travailler main dans la main avec le fabriquant de l'OS pour suivre les évolutions des hash. Derrière il faut que l'OS dispose lui d'un moyen de se certifier "tout seul" - ce qui est faisable mais descend la sécurité à un niveau plus bas - et de remonter cette certification via la TPM.
De plus normalement les puces TPM ne peuvent pas être livrées pré-certifiées (la norme l'interdit spécifiquement, et celà limiterait ennormément leur usage), et qu'il faut donc que l'utilisateur a) active la puce t b) la remplisse lui même au moins au début - a noter cependant que ca n'est pas techniquement impossible, et que il se peut très bien que les constructeurs changent d'avis. Mais il est plus probable qu'ils utilisent un système supplémentaire basé sur TPM mais qui possède des fonctions et des mémoires séparées pour faciliter la validation/activation du hardware et du software morceau par morceau (c'est le système LaGrande d'Intel, et c'ets de loin celui qui me fait le plus peur).