Après les routeurs troués, les smartphones, dont Archos : http://www.numerama.com/tech/218593-archos-zte-et-lenovo-sont-aussi-empetres-dans-laffaire-du-backdoor-chinois.html
Il est grand temps d'avoir du matériel Open Source avec des OS comme Replicant. Qu'en est-il des projets en cours ?
Journal Des p'tits trous, des p'tits trous, toujours des p'tits trous
21
déc.
2016
# Chipsets sympathiques ?
Posté par karteum59 . Évalué à 9.
Malheureusement je ne vois aucun chipset (MTK, QCA, Samsung…) permettant d'avoir des fonctionnalités "modernes" (Cortex A*, 802.11ac, 4G/LTE…) sans nécessiter des blobs propriétaires, le tout dans un unique device de type "smartphone". Probablement que la seule solution "à peu près de confiance" est d'avoir un ordi correct (e.g. Lenovo x200/t400 sous Libreboot + Linux) + un dongle USB 4G (qui nécessitera peut-être des blobs fermés mais n'aura pas accès à la RAM/stockage ni aux interfaces du T400). Mais évidemment c'est un peu moins portable qu'un smartphone…
En attendant et à défaut de Replicant, fonctionner sous Cyanogenmod (et se limiter aux marques de smartphones qui respectent la GPL) est un moindre mal… ça ne protège pas des spywares qui pourraient être intentionnellement introduits par Qualcomm dans les blobs, mais au moins ça protège de tout ce qui est introduit par l'OEM dans le firmware Android (cas probablement le plus fréquent, et évoqué ici).
[^] # Re: Chipsets sympathiques ?
Posté par rdhlnn . Évalué à 6.
Tu penses à qui ? Ou est-ce tous les smartphones qui tournent sous CM ?
[^] # Re: Chipsets sympathiques ?
Posté par Larry Cow . Évalué à 4.
Plus proche du smartphone : un smartphone escouillé, dont les modules de communication réseau (liste à déterminer) sont déportés dans un boîtier externe - dongle USB par exemple, comme tu suggères.
Pour empêcher le smartphone de communiquer sans permission, virer la carte SIM ne suffit pas, mais on peut envisager de pourrir une (des?) antenne(s).
La question de la communication avec le boîtier externe. L'USB c'est bien, mais est-on certain que ça suffit à se sentir protégé? Est-ce qu'une option sans-fil (BT? WiFi? ZigBee?) ne serait pas plus sympathique? Çà implique une batterie, certes.
[^] # Re: Chipsets sympathiques ?
Posté par Ph Husson (site web personnel) . Évalué à 4.
Enlever les antennes ne répond pas, AMHA au problème.
S'il y a un agent dans le modem qui va lire le buffer tournant de toutes les interfaces réseaux du kernel, et qui peut y injecter du trafic, t'as perdu (oui arriver à faire ça est d'une complexité assez impressionnante, il n'empêche que c'est faisable)
Maintenant, sur la plupart des ces plate-formes, le modem est chargé assez tard dans le processus de démarrage.
La plupart le démarrent après Linux.
Il suffit donc de ne PAS le démarrer.
Après il n'y a, de loin, pas que le modem qui a les droits sur la mémoire.
On est sur des plate-formes tout-intégrées, tous les composants qui ont besoin de RAM iront la chercher au même endroit.
Si je dois lister les composants externe au processeur principal qui ont accès à la RAM, on a par exemple sur un Qualcomm le GPU 3D, le GPU 2D, le codec video, la gestion de la mise en veille. Tu parles de communication sans-fil avec autre chose, mais le bluetooth et le WiFi aussi sont des éléments proprios qui ont accès à la RAM. Et il m'en manque probablement plein.
La bonne nouvelle, c'est que toutes les plate-formes modernes possèdent des IOMMU, qui permettent au processeur principal d'autoriser explicitement quel composants ont accès à quelle zone de la RAM.
Mais ces IOMMU étant fondue dans la puce, il n'existe aucun moyen réalisable de le vérifier.
Si on suppose que le hardware ne ment pas (ce que l'on fait la plupart du temps sur x86), alors la situation actuelle est suffisante: le système est protégé et cloisonné par l'IOMMU.
Si on ne fait pas cette confiance, la seule et unique solution est un hardware libre.
# My 2 cents
Posté par Ph Husson (site web personnel) . Évalué à 10.
Sommaire
Premier point, pour ce que ça vaut, les téléphones et tablettes Archos ont été protégé contre ce malware dans les 36 heures après l'annonce de Kryptowire du 15 novembre.
C'est l'occasion pour moi d'essayer d'expliquer ici l'écosystème Android.
Mon commentaire est très touffu, mais j'espère qu'il est quand même intéressant.
L'architecture commerciale d'Android
Voici une petite explication rapide de comment ce genre de choses peut arriver.
Android est fourni par Google en open-source en Apache2 (BSD-like), sous le nom de AOSP (Android OpenSource Project). Mais contrairement à ce qu'on pourrait par exemple voir sous Windows, Google n'impose pas d'utiliser sa propre version, il existe donc un très grand nombre dérivés.
Globalement il existe une poignée de concepteurs de puces capables de faire des puces tout intégré (WiFi/4G/Bluetooth/GPU/audio/….) de téléphones Android.
Ces concepteurs font donc une version modifiée d'Android pour inclure les drivers associé à leur puces, et surtout font une quantité assez faramineuse de modifications en tout genre. Par exemple, à une époque il s'agissait d'ajouter le support de multiples SIMs dans un téléphone, mais il peut aussi s'agir de requêtes faites par des opérateurs (par exemple afficher 4G+ dans les icônes, ou HD pour les codecs audio ""HD"").
Déjà à cette étape, la plupart des concepteurs de puces laissent des binaires.
Ensuite, il existe deux cas.
Soit il s'agit d'un gros constructeur, pour un produit vendu par millions.
Auquel cas, ce constructeur récupère directement l'Android modifié du concepteur de puces. (À ma connaissance, les exceptions ici sont Samsung et Huawei parce qu'ils sont leurs propres concepteurs de puces, et Sony)
Soit il s'agit de plus petits produits, auquel cas on arrive á une nébuleuse qu'on appellera concentrateur électronique. Il va acheter les puces aux concepteurs par millions, et va faire des PCBs avec ces puces et les différents éléments "utiles" (RAM/stockage, accéléromètre, les différents connecteurs, PMIC, …) aussi par million.
Dans ce cas, le concentrateur va modifier la version d'Android fournie par le concepteur de puces pour inclure les drivers des composants qu'il vient de souder. Ici aussi, il leur arrive d'être plus imaginatif et faire des modifications plus évoluée que juste rajouter des drivers.
Alors, le constructeur "final" du téléphone va récupérer cette version d'Android.
Il existe donc quatre intermédiaires entre la version open-source et la version finale, et l'utilisateur.
À chacune de ces étapes, il y a bien évidement des sous-traitants en pagaille. Dans ce cas ici présent, il s'agit d'ADUPS. Sur le papier il fournit un système de mise-à-jour en-ligne, ce qui parait légitime.
Il se trouve que cette application s'avère malveillante.
Mais il ne faut pas se leurrer, il y a probablement vingt entreprises qui ont la possibilité de mettre un malware pour un constructeur de téléphone.
Celui-ci a été trouvé presque par un concours de circonstance:
Les chercheurs en sécurité ont tendance à toujours utiliser des téléphones haut de gamme, et rentrent donc dans la catégorie des téléphones produits par millions, pour lesquels un soin tout particulier a été apporté.
Ici, le smartphone "original" avait un prix réduit en échange d'un peu de publicité affichée par Amazon, c'est pour ça qu'il a été acheté par ce chercheur.
Au final, ce chercheur a trouvé un malware qui touche 1 Milliard de téléphones.
Mais étant donné le nombre d'intermédiaires, de très nombreux malwares passent à l'heure actuelle à la trappe.
Les failles de sécurité
Un autre point important à considérer en terme de sécurité est l'application des correctifs de sécurité.
Google publie ses patchs de sécurité pour AOSP mensuellement.
Si vous avez bien suivi le paragraphe précédent, vous pouvez tenter de répondre à la question suivante:
Combien de temps faut-il pour que les patchs de sécurité de Google arrivent dans la main des clients?
…
Oui, très longtemps.
J'ai dit précédemment que le chercheur n'a quasiment que eu à se baisser pour trouver des problèmes.
Similairement, il y a deux ans, Android n'était pas vraiment audité, et les chercheurs n'ont eu qu'à se baisser pour trouver des failles.
De nos jours Android est bien mieux fortifié, mais il existe encore très régulièrement des failles critiques (deux le mois dernier: http://source.android.com/security/bulletin/2016-11-01.html ).
Et Google n'est pas connu pour faire du code complètement troué, les vingt sous-traitants intermédiaires font probablement du code bien pire que Google…
Android open-source
Comme signalé plus haut, il y a pas mal de solutions Quick&Dirty disponibles pour "libérer" son téléphone, qu'on appelle communément des ROMs.
Ici, tous les drivers restent sous forme binaire, et il y a évidement un très grand nombre de blobs.
À noter qu'un grand acteur parmi les ROMs open-source est Qualcomm. En effet, ils publient les sources de leurs modifications à Android, et d'une partie de leur drivers.
Sinon, pour des plus puristes, il existe effectivement Replicant, comme tu le signales justement.
Je connais très peu Replicant, néanmoins j'en sais juste qu'ils font un travail assez remarquable, mais se limitent parfois un peu trop à mon avis. (cf l'interdiction de firmwares wifi proprio)
Android sur un kernel upstream
Maintenant, un autre point sur lequel je veux discuter est sur l'upstream. Il s'agit principalement de Linux, mais pas que.
Android se base sur un grand nombre d'abstraction matérielle-logicielle en espace utilisateur. Au moment de leur création, l'équivalent upstream n'existait pour ainsi dire pas.
Mais ce n'est plus entièrement vrai de nos jours. Si on prend une tablette pour un usage simple, il existe une interface "standard GNU/Linux" pour tout ce dont Android a besoin.
"Le chaînon manquant" est donc d'avoir des HALs Android, utilisant par derrière des interfaces standard.
Ici, il y a beaucoup de travail, mais il manque d'une grande centralisation!
Par exemple, une des abstractions nécessaires est celle permettant de faire le rendu 2D, il s'agit de hwcomposer.
La fonctionnalité Linux équivalente la plus proche (sans être strictement équivalente) est drm.
Il existe drm_hwcomposer qui remplit donc les fonctionnalités de cette HAL par DRM. La blague? J'arrive même plus à compter combien de versions différentes il existe. (Je compte celle utilisée par freedreno, celle utilisée par Google dans ChromeOS, celle d'Intel, celle d'Android-x86, et je sais que certains constructeurs en ont aussi des versions internes).
Si on prend l’accéléromètre (qui permet principalement de trouver l'orientation de l'écran), il existe une interface standard, iio.
À ma connaissance, il existe une abstraction pour ça, celle d'Intel.
On peut parler du rendu 3D, ici il n'y a pas vraiment d'API à proprement parler, mais Mesa est maintenant capable de cibler Android.
À noter que ici, j'attends une poussée importante grâce à la possibilité d'exécuter des applications Android sur ChromeOS.
ChromeOS se base en très grande partie sur des APIs existantes dans Linux upstream, et leur manière d'exécuter des applications Android consiste à mettre Android dans un LXC.
Néanmoins, il existe de nombreux domaines pour lesquels il n'existe pas d'API standard GNU/Linux:
- la communication avec la partie téléphonie/4G
- des fonctionnalité basses consommation, par exemple le "Ok Google" alors que le téléphone est en veille
- des fonctionnalités WiFi avancées, par exemple la mesure du temps-de-vol
Des téléphones et tablettes Android avec un kernel upstream
J'ai parlé de l'étape "Si j'ai un kernel mainstream qui marche, alors je peux avoir Android", parlons de l'inverse: "j'ai une tablette Android, est-ce que je peux avoir un kernel mainstream?"
Ici, les choses avancent globalement dans le bon sens.
Je pense que ce mouvement est principalement lié à Google, mais pas pour Android.
Pour ChromeOS et pour Android IoT, Google requiert (Source: https://lwn.net/Articles/706597/) de la part des concepteurs de puce d'au moins essayer de merger leurs drivers en mainstream.
De manière plus ou moins corrélée, on a pu voir sur la LKML, s'agiter un certain nombre de constructeurs pour faire inclure leur changements (Qualcomm, Rockchip, Mediatek).
On arrive à un point où on peut trouver des tablettes existant pour de vrai sur le marché qui ont la quasi-intégralité de leur drivers mainstreamé.
Je prends par exemple la tablette Archos 101 Oxygen (le concepteur de puces ici est Rockchip)
Il est possible de lui mettre un bootloader u-boot mainstream, kernel mainstream, driver wifi mainstream, driver GPU 2D mainstream, accéléromètre mainstream, écran mainstream (en trichant un peu).
Le décodage de vidéo matériel, bien que non mainstreamé (mais soumis à la LKML), est disponible en libre par des APIs standard (VA-API, VDPAU et gstreamer).
Principale ombre au tableau ici, le driver Lima (implémentation libre pour GPU 3D Mali) qui s'est fait tué dans l'oeuf.
Il faut aussi évidement parler de l'énorme travail de Free-Electrons pour mainstreamer un support Allwinner.
Il me semble qu'ici aussi, on a un support suffisant pour être utilisable de certaines tablettes Allwinner.
[^] # Re: My 2 cents
Posté par bunam . Évalué à -10.
Je trouve que tout cela n'est que du vent, tout est ouvert aux 4 vents.
En fait Google a fait mieux dans le pire que Microsoft ;) Tout ça à cause de la "menace" Apple et son iPhone.
S'il avait eu un comportement responsable, il n'aurait pas permis tout ça. Et c'est trop facile de dire c'est pas moi, c'est les autres.
Il a permis ces aberrations, car sinon il n'aurait jamais pu espérer imposer son système : Chapeau, car tout le monde (80% ?) est tombé dans le panneau !
[^] # Re: My 2 cents
Posté par Psychofox (Mastodon) . Évalué à 5.
Tu pourrais remplacer google par Debian ce serait pareil.
N'importe qui pourrait en théorie vendre des téléphones avec une backdoor dedans en disant qu'ils fournissent l'OS "Jessie"
[^] # Re: My 2 cents
Posté par bunam . Évalué à 1.
Alors on change rien et on laisse faire ?
Trou aussi et morts comme consequences :
http://www.numerama.com/politique/218963-la-russie-aurait-piste-lartillerie-ukrainienne-avec-un-malware-android.html
[^] # Re: My 2 cents
Posté par Maclag . Évalué à 2.
Je trouvais déjà que la Défense Française cartonnait avec ses contrats MS, mais là du je comprends bien:
Un militaire a développé un truc pour Android (pour téls perso??) et l'a diffusé sur un équivalent FB à ses potes?!
Ça me semble très professionnel tout ça!
[^] # Re: My 2 cents
Posté par Foutaises . Évalué à 3. Dernière modification le 24 décembre 2016 à 09:26.
Ça me semble totalement bidon comme information. Je ne sais pas ce qu'il en est en Ukraine, mais en France, que ce soit dans l'armée ou dans la gendarmerie (en tout cas au moins en école pour cette dernière), tu n'embarques pas de téléphone avec toi sur le terrain en intervention (pas plus qu'à l'entraînement). À moins qu'il n'y ait eu du changement ces dernières années, les militaires ont un uniforme et un paquetage réglementaires, et tout le reste est interdit (bijoux, piercings, etc. inclus, il faut les retirer).
[^] # Re: My 2 cents
Posté par Kerro . Évalué à 6.
Je connais un seul gendarme. Il semble toujours avoir son téléphone portable perso sur lui.
Idem pour les policiers nationaux et municipaux que je connais un peu.
Ça semble donc être courant.
[^] # Re: My 2 cents
Posté par Psychofox (Mastodon) . Évalué à 3. Dernière modification le 25 décembre 2016 à 21:09.
Non mais ça n'a rien à voir.
Il y'a sûrement des choses à améliorer mais là tu mets la responsabilité d'un truc dans google alors que c'est de la responsabilité des constructeurs de téléphones de s'assurer que leurs fournisseurs ne leurs livrent pas n'importe quoi.
[^] # Re: My 2 cents
Posté par ʭ ☯ . Évalué à 10.
Merci pour les détails, c'est carrément un journal dans le journal. Que dis-je? Une dépêche dans un journal!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: My 2 cents
Posté par reynum (site web personnel) . Évalué à 3. Dernière modification le 22 décembre 2016 à 11:09.
Mais c'est génial ça ! si seulement ils pouvaient le faire aussi pour Android :) ce serait la panacée, des drivers mainstream pour toutes les parties des smartphones \o/.
Que de mauvais souvenirs …
D'ailleurs quand j'ai vu le titre de cette dépêche j'ai bondi de ma chaise puis me suis rassis après avoir compris qu'il n'y avait pas de rapport.
Mais bon, ne perdons pas espoir qu'une autre personne (que Luc Verhaegen) reprenne le flambeau d'un driver libre pour Mali, ou qu'avec l'arrivée de Vulcan ces GPU soient utilisables par des noyaux récents.
kentoc'h mervel eget bezan saotred
[^] # Re: My 2 cents
Posté par Ph Husson (site web personnel) . Évalué à 4.
Pas besoin d'attendre Vulkan.
Les tout derniers drivers Mali sont utilisables sur un 4.9 en module (i.e. sans modification du kernel, juste du dts) (https://github.com/phhusson/rockchip_forwardports)
J'en ai pas parlé parce que ces drivers restent inutilisables pour Android du fait des linkers incompatibles (et probablement API incompatible aussi). Je me suis posé la question de chercher un proxy GLES pour combler ce trou mais bon…
En attendant, pour un système GNU/Linux il est pleinement utilisable. Il existe en API X11/FrameBuffer, et maintenant Wayland!
Paradoxalement, ce que j'attends du support Vulkan, c'est le support d'OpenGL (non-ES).
On devrait voir assez rapidement apparaître des implémentations OpenGL au-dessus de Vulkan,
et donc quand Mali aura publié son support Vulkan, on aura tous les jeux de la terre libre \o/
[^] # Re: My 2 cents
Posté par reynum (site web personnel) . Évalué à 3.
Super j'ignorais cela en plus le github pour compiler c'est royal (même si c'est board specific ;-)).
Effectivement je n'avais jamais pensé à cette possibilité, qui en plus pourrait, avec une une gestion plus fine du bas niveau augmenter les performances de l'implémentation OpenGL. :-)
kentoc'h mervel eget bezan saotred
[^] # Re: My 2 cents
Posté par Ph Husson (site web personnel) . Évalué à 2. Dernière modification le 22 décembre 2016 à 14:00.
Effectivement j'avais oublié la section plateforme-spécifique du driver, mais c'est de mémoire c'est pour la gestion de l'énergie: mise en veille, réglage de tension, réglage de fréquence.
Si t'as déjà eu à une époque un driver mali pour ta plate-forme ça devrait pas poser trop de problème.
Au fait, t'as une plateforme en tête?
J'ai comme objectif de faire un dkms mali, si c'est possible d'en faire un qui supporte un maximum de plateformes ça serait cool!
Meh, ça j'y compte pas, j'espère bien que les constructeurs sont plus capables de faire des drivers en accédant directement à leur registres hardware, qu'un mec dans son garage qui utilise une sur-couche intermédiaire…
Enfin je sais pas, c'est vrai que OpenGL est devenu une telle usine à gaz, que bien splitter les deux peut aider.
[^] # Re: My 2 cents
Posté par reynum (site web personnel) . Évalué à 2.
Oui j'ai une Pine A64 (Dual Core Mali 400 MP2) dessus il y a une ROM officielle mais j'aimerais compiler un noyau plus récent qu'un 3.10 et je crois que le blob binaire pour le GPU ne gère que ce noyau :-)
kentoc'h mervel eget bezan saotred
[^] # Re: My 2 cents
Posté par Ph Husson (site web personnel) . Évalué à 4.
Erf j'avais raté l'autre morceau de ton commentaire
Je ne vois pas ça arriver à court terme, Google a trop perdu le contrôle de son écosystème Android pour ça.
Maintenant, il faut quand même être optimiste. Dans le monde {Chromebook,Android IoT,Android} l'intersection est assez énorme.
Typiquement on a pu voir arriver sur la LKML des patchs pour le rk1108, qui est la puce pour Android IoT de Rockchip.
Elle réutilise à peu près tous les composants Rockchip déjà existant.
J'ai donc assez bon espoir pour, entre-autre, Qualcomm et Mediatek, globalement le delta pour passer de la plate-forme Android IoT à la plateform smartphone devrait être inclut dans le delta entre Android IoT et Chromebook.
Pour les plus petits concepteurs de puces, il y a aussi d'autres intersections. Les modules les plus complexes qu'ils intègrent dans leur puce sont en général pas fait par eux-même, mais acheté à des entreprises externes.
Typiquement, NXP et Rockchip utilisent le même composant HDMI, conçu par Synopsys.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.