M a écrit 2996 commentaires

Sympa comme article.

Par contre pour étoffer tu aurais pu aborder l'opérateur ','.

int* i,j;

'j' est il un entier ou un pointeur d'entier ?

Il y a aussi des subtilité avec le const.

'const char *p' vs 'char * const p'.

The scheme we propose is built around the variety of concepts of btrfs and Linux file system name-spacing. btrfs at this point already has a large number of features that fit neatly in our concept, and the maintainers are busy working on a couple of others we want to eventually make use of.

On va devoir tous passer sur brtfs si on utilise systemd ?

I originally intended to discuss this at the Linux Plumbers Conference (which I assumed was the right forum for this kind of major plumbing level improvement), and at linux.conf.au, but there was no interest in my session submissions there…

…

Je confirme, mon disque de 3 To à table GPT est très bien géré par le BIOS de ma machine.
Ca doit fonctionner vu que gpt met un faux mbr : http://en.wikipedia.org/wiki/GUID_Partition_Table#Legacy_MBR_.28LBA_0.29

Je trouve que l'article de la FSF y va un peu fort. C'est proprio mais y a des spec.
Je peux aussi récupérer du code libre des années 70, si personne de l'a maintenu, il n'y aura plus forcément le compilo et l'environnement pour l'utiliser.
Enfin GNU radio aurait pu être proprio, ça n'aurait pas changé ces fonctionnalités.

En parcourant rapidement l'article de wired (http://www.wired.com/2014/07/usb-security/) on lit :

The malware they created, called BadUSB, can be installed on a USB device to completely take over a PC, invisibly alter files installed from the memory stick, or even redirect the user’s internet traffic. Because BadUSB resides not in the flash memory storage of USB devices, but in the firmware that controls their basic functions, the attack code can remain hidden long after the contents of the device’s memory would appear to the average user to be deleted.
…
They spent months reverse engineering the firmware that runs the basic communication functions of USB devices—the controller chips that allow the devices to communicate with a PC and let users move files on and off of them. Their central finding is that USB firmware, which exists in varying forms in all USB devices, can be reprogrammed to hide attack code.

Franchement il y a rien de nouveau. Les devices usb font tourner des firmware et sur certains il est possible de les reprogrammer. On peut faire tourner des device usb sous linux (par exemple les téléphone android).
Ayant contrôle sur le device on peut faire des clefs usb pour lequel on ne peut pas effacer les fichier (un virus par exemple) (malgrès le reformatage) ou qui stocke des info de manière permanente.
On peut faire aussi en sorte que notre clef usb simule un clavier, une carte réseau, … pour tenter d'injecter/récuper des infos.

Mais de la à dire que l'USB à une énorme faille de sécu…
Le plus simple serait que les OS aie un moyen de demander à l'utilisateur s'il veut activer tel fonctionnalité du périphérique qui vient d'être branché.
D'ailleurs c'est déjà possible sous linux : https://www.kernel.org/doc/Documentation/usb/authorization.txt

Firefox va ensuite vérifier en cherchant si les caractéristiques correspondent aux listes de blocage et d’autorisation. Si le binaire ne correspond ni à un téléchargement de confiance, ni à un téléchargement suspect, Firefox va vérifier la réputation du site.

En lisant la description sur le site de mozilla (https://wiki.mozilla.org/Security/Features/Application_Reputation_Design_Doc ), on peut voir qu'il est prévu (sous windows) de faire des requêtes distante pour vérifier le fichier.
C'est super mais niveau de la confidentialité, ça veut dire que ce/ces serveurs sont au courant de tout les fichiers qu'on télécharge…

Récemment, ils ont décidé de revenir sur la glibc, le mainteneur est parti et le steering committe s'est dissout.

Il n'ont pas forcement eu trop le choix. Les personnes a l'origine de eglibc pousse pour un retour vers glibc :
http://www.eglibc.org/home

EGLIBC is no longer developed and such goals are now being addressed directly in GLIBC.
[…]
This is the final release branch of EGLIBC; users and developers should now move back to GLIBC and develop it as needed in accordance with the goals of EGLIBC.

C'est le cas de tout les bus asynchrone ou le master génère une clock et le slave répond en fonction de cette clock. Après les termes on parfois été remplacé par host/device, mais ça reste la même chose.

Et c'est le cas pour l'i2s, le pcm, sdcard, sdio, …
Bref quasiment tout sauf le rs232.

Il y a de ça quelques mois, la société Kaspersky découvre un logiciel malveillant installé sur au moins 2 millions d'ordinateurs.
Computrace se divise en 3 modules présents dans l'option ROM PCI qui est chargée ensuite par le BIOS de la machine.

Ils ont l'air a la ramasse, en faisant une recherche sur le net, je suis tombé sur un article de 2009 qui explique le fonctionnement de computrace :
http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf

La board resemble a une Cubieboard2 ? http://fr.wikipedia.org/wiki/Cubieboard2

On peut trouver des info sur le Allwinner A20 sur http://linux-sunxi.org/A20

Les GPUs non-intégrés non-mobiles supportent entièrement le pipeline programmable requis par WebGL depuis que le GeForce 6 est sorti en 2004, il y a 10 ans, suivis par les Radeon l'année suivante je crois;

Oui mais quand sont elles sorties en version entrée/moyen de gamme ?

Ca serait intéressant d'avoir la proportion des configs qui marche bien avec opengl (pas désactivé a cause du matériel ou des question de sécurité).

Après le DES (1978), la NSA a quand même promu des algos sûrs

Mais elle a aussi introduit des backdoors dans certains algos : http://en.wikipedia.org/wiki/RSA_BSAFE

Ils ont commité comme des petits fous (on parle de 250 commits à 8), et sont arrivés à un résultat assez intéressant: en virant tout les machins spécifiques à VMS et Windows, ils ont viré la moitié du bloat qu'il y avait, et toutes les applis dans l'arbre OpenBSD continuent de compiler. Pas mal.

Faire plein de commit et que le code continue a compiler, pas mal de monde sait le faire.

Par contre être sur que l'on introduit pas de subtile régression ou trou de sécu c'est beaucoup plus dur. Surtout dans les algos de crypto où il peut avoir des attaques temporelles : http://fr.wikipedia.org/wiki/Attaque_temporelle.

Enfin c'est bien beau de faire un fork mais si personne ne l'utilise, il ne sera jamais audité et aura potentiellement plein de trou.
Il y a plein de lib ssl (gnutls, …) ou de lib de crypto, mais c'est pas pour rien que les failles sont divulguées sur les plus utilisées.

Y a une opportunité, mais il ne faut pas ce leurrer, les softs (de bureau) qui tournent bien sur du matériel de l'époque de XP ne sont pas toujours bien maintenu.

il y a fort à parier que d’autres fabricants de GPU (surtout ARM) s

Sur arm le driver kernel est déjà opensource :
http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-gpus-linux-kernel-device-drivers/

Comme le processeur baseband peut de toute facon acceder a tout ce qu'il veut

Tu as des liens qui explique comment celui est connecté ?
Sinon c'est facile de raconter n'importe quoi…

oui mais le problème n'est pas d'écrire le mot de passe, le problème est de laisser trainer le bout de papier.

Surtout que sur le bout de papier on n'est pas obligé de mettre a quoi correspond explicitement le mot de passe ou tu peux appliquer une petite transformation (le lire de droite a gauche, …)

Donc même si on le perd la personne qui le trouve ne sera pas a quoi ca correspond.

Sauf que sur la voiture que je conduis, le couple du moteur est tellement camionesque que freiner alors que le moteur est à fond est juste illusoire.

Tu as déjà fait des tests ?
Tu ne cales jamais ?

A haute vitesse tu es sur un rapport élevé, donc le couple moteur est d'autant réduit. Ca parrait fou que le frein ne prenne pas la main.

Après m'être pas mal documenté sur ce problème et ne comprenant pas pourquoi la voiture n'a pas freiné alors que la liaison physique entre la pédale de frein et les étriers est une obligation

Cette obligation n'est pas contradictoire avec les voitures "brake-by-wire" qui ont l'air d'être déjà dans la nature : http://en.wikipedia.org/wiki/Electronically_Controlled_Brake

ça ne parle pas du tout du système de freinage (qui était évidemment avec une liaison hydraulique avec les roues et dont le bon fonctionnement n'a pas été mis en cause).

Pourtant si je freine et que j'accélère en même temps le moteur cale ?

Au passage Toyota fait des voiture avec des freins sans liaison hydraulique
http://en.wikipedia.org/wiki/Electronically_Controlled_Brake

Electronically Controlled Brake (ECB) developed by Toyota Motor Corporation initially for its hybrid and Lexus models, is the world's first production brake-by-wire braking system.

2001 Toyota Estima Hybrid
2002 Toyota Alphard
2006 Toyota Highlander Hybrid
2006-2009 Lexus RX 400h
2005-2007 Lexus GS 430
2007 Lexus GS 450h
2007 Lexus LS 460
2008 Lexus LS 600h
2008 Lexus GS 460
2010 Lexus RX 450h
2011 Lexus LFA

Y a un truc que je ne comprends pas : le freinage sur cette voiture est entièrement électronique ?

Ben déjà le freinage n'est plus 100% mécanique sur aucune voiture récente avec l'ABS (obligatoire sur les voiture récente en europe) et autres assistances de freinage qui vienne modulé le freinage à ta place.

Ensuite sur wikipedia on peut voir que les constructeurs développent des solutions de frein électronique : http://en.wikipedia.org/wiki/Brake-by-wire

Et Toyota fait partie des précurseur :

So far, Mercedes-Benz (Sensotronic) and Toyota (Electronically Controlled Brake) already use almost fully brake-by-wire systems, on the Mercedes-Benz E-class and SL models and on Toyota's Estima.

On le fait très bien sur un avion, qui est bien plus complexe qu'une voiture.

C'est pas non plus les même condition d'utilisation. Déjà dans un avion tu es dans le ciel tu as plein d'espace, en théorie plus de temps pour réagir.
Ensuite il me semble qu'ils ont pas mal de solution de secours prévu.

on ne ressent pas de crainte dans le métro, le train ou l'avion, pourtant rien n'y est sous notre contrôle!
Mais il y a encore des humains derrière. Même pour le métro automatique il y a un poste de contrôle qui peut couper le courant si un métro devient fou.

Laisser sa vie entre du logiciel (surtout quand on voit comment c'est fait) sans aucun contrôle ça parait suicidaire.

Ce que je trouve fou c'est que dans ces voitures (surtout les automatiques) il n'y a rien de prévu (mécanique) en cas de défaillance du logiciel.

En effet sur les voiture automatique moderne :
- on ne peut pas tourner la clef quand une vitesse est engagé
- on ne peut pas débrayer (pas de pédale)
- l'accélérateur n'est pas cablé en direct mais relié à un ordinateur gérant la boite de vitesse/accél moteur
- le frein non plus ne doit plus être en direct avec les histoire d'abs.

Sur une voiture à vitesse manuelle on peut espérer que l'embrayage soit encore relié en direct.

Sur les anciennes voitures ou tout était câblé en direct :
- le frein lâche : on peut toujours rétrograder
- l'embrayage lâche : on peut freiner
- l'accélérateur se coince : on peut freiner/débrayer/couper le contact

Par exemple dans le cas de la direction assisté, le volant continue d'être relié en direct avec la direction. En cas de défaillance, le conducteur a toujours le contrôle du véhicule (avec une direction plus dure). Je sais pas si c'est toujours le cas aujourd'hui.

Je pense qu'on ne sera jamais capable d'écrire du logiciel 100% bug free et qui faut avoir des moyen pour prendre le contrôle du véhicule de manière mécanique.

Pour l'usb c'est pas eux qui ont fait le contrôleur. C'est de mémoire un dwc otg fait par synopsys.
Ce contrôleur est utilisé sur d'autre SOC et la doc est fournie par synopsys à ceux qui achète leur block hardware.

Après le contrôleur n'est pas forcement fabuleux, donc doc ou pas doc il faut pas en espérer des merveille…