Forum openmoko-fr.org

Forum de la communauté francophone autour du projet OpenMoko

Vous n'êtes pas identifié.

Annonce

Bienvenue sur ce forum.

Face à un afflux de spammers, les inscriptions ont été désactivée.
Si vous souhaitez vous inscrire, il faudra en faire la demande auprès du webmaster (voir la section "Contact" sur le Blog).

#1 09-09-2008 18:50:32

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Projet de recherche sur OpenMoko

Bonjour à tous,

À l'occasion de la soirée de présentation à La Cantine, j'ai découvert une communauté motivée par ce projet et très éclectique. Elle comprend également des chercheurs, dont malheureusement je n'ai pas pu récupérer les coordonnées, dans le domaine des méthodes formelles. Envisageant de monter un projet de recherche ANR autour du FR (voir présentez-vous), merci de me contacter par mail.

Mokamicalement,

Dernière modification par FlorentBL (11-09-2008 15:01:02)


Mokamicalement,
Florent Chabaud

Hors ligne

 

#2 11-09-2008 09:55:25

youshe
Fun-Moko
Date d'inscription: 06-08-2008
Messages: 73

Re: Projet de recherche sur OpenMoko

Question, les dits chercheurs étaient d'où ? S'ils étaient de grenoble (plusieurs équipes s'intéressent aux preuves formelles ici), peut être que je pourrais les retrouver.

Fred

Hors ligne

 

#3 11-09-2008 12:01:22

olberger
Moko
Date d'inscription: 25-07-2008
Messages: 14

Re: Projet de recherche sur OpenMoko

Quel rapport entre preuves formelles et OpenMoko ??

Hors ligne

 

#4 11-09-2008 15:00:47

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

youshe a écrit:

Question, les dits chercheurs étaient d'où ? S'ils étaient de grenoble (plusieurs équipes s'intéressent aux preuves formelles ici), peut être que je pourrais les retrouver.

Fred

Si je le savais ce serait simple ! J'espère juste qu'ils se reconnaîtront, il y avait notamment un grand noir accro à Coq. (pas la coke, coq smile)


Mokamicalement,
Florent Chabaud

Hors ligne

 

#5 11-09-2008 15:07:17

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

olberger a écrit:

Quel rapport entre preuves formelles et OpenMoko ??

Pas de rapport direct, si ce n'est que les preuves formelles permettent d'envisager de créer des logiciels prouvés ne comportant pas de bug (je simplifie volontairement, c'est un peu réducteur). Si on essaie de faire cela pour un système d'exploitation, on obtient le saint graal de l'informatique : un truc stable impossible à planter et donc beaucoup plus sûr que tout ce qui existe. Un seul problème, pour pouvoir faire un système d'exploitation formellement prouvé, il faut pouvoir modéliser la plate-forme matérielle. Et c'est là qu'OpenMoko, dans sa partie matérielle, devient intéressante, car modéliser une plate-forme dont une partie des spécifications est fermée c'est tout simplement impossible et si on ne rentre pas assez dans les détails, la modélisation ne rend pas compte de la réalité.


Mokamicalement,
Florent Chabaud

Hors ligne

 

#6 11-09-2008 20:03:08

youshe
Fun-Moko
Date d'inscription: 06-08-2008
Messages: 73

Re: Projet de recherche sur OpenMoko

Euh, preuves d'OS, ça me fait beaucoup penser au projet coyotos (http://www.coyotos.org/) où le but, si je me souviens bien est de créer, au dessus d'un micro-noyau, un ensemble de serveurs (au sens micro-noyau du terme) prouvés formellement. Dans le cadre de ce projet, on retrouve en particulier le langage bitC qui est un dialecte de lisp possédant des primitives bas niveau. Donc langage fonctionnelle, potentiellement prouvable "aisément" avec la rapidité du C.
D'un autre coté, plus de travail a peut être été fait au niveau de la portabilité sur le projet l4 qui doit aussi avoir des idées de preuves formelles dans quelques thèses ou recherches wink

Fred

Hors ligne

 

#7 13-09-2008 02:45:45

khorben
Cool-Moko
Lieu: Berlin, Allemagne
Date d'inscription: 13-09-2008
Messages: 42
Site web

Re: Projet de recherche sur OpenMoko

Bonsoir,
j'étais également présent lors de la soirée Openmoko. Je progresse (bien que trop doucement) sur RunningBear, l'OS créé par Bearstech notamment pour l'Openmoko. Je compte bien faire attention à sa sécurité, et à la possibilité de le convertir facilement pour des usages bien différents de la téléphonie.
Bref, je vais publier le code disponible et le documenter aussi vite que possible, et j'espère bien pouvoir proposer des briques de base pour ce genre de projet.
HTH, Pierre Pronchery

Hors ligne

 

#8 13-09-2008 09:04:13

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

khorben a écrit:

Bonsoir,
j'étais également présent lors de la soirée Openmoko. Je progresse (bien que trop doucement) sur RunningBear, l'OS créé par Bearstech notamment pour l'Openmoko. Je compte bien faire attention à sa sécurité, et à la possibilité de le convertir facilement pour des usages bien différents de la téléphonie.
Bref, je vais publier le code disponible et le documenter aussi vite que possible, et j'espère bien pouvoir proposer des briques de base pour ce genre de projet.
HTH, Pierre Pronchery

Bonjour,

Tout pareil, je progresse (trop doucement) dans ma prise en main de la bête wink

J'ai installé la debian et je confirme qu'elle implante bien la séparation des privilèges (on peut faire un useradd). Toutefois, j'ai l'impression que ce n'est pas très utilisé (tout semble se lancer en root également).
Par ailleurs, je comprends du process que le noyau initial reste inchangé. Si je comprends bien la séquence de boot on a :
- u-boot qui se lance (on sélectionne boot sur sd-card)
- le noyau openmoko qui se lance
- montage de la partition root sur sd-card et boot linux
Donc quelle que soit la distrib, on a intérêt à upgrader le noyau OM.

Qqun peut confirmer ce point ?

Question subsidiaire : puisque le noyau et le système de fichiers OM sont contigus en mémoire (d'après ce que j'ai compris de ton talk vendredi à la Cantine) comment gère-t-on un noyau de taille différente du noyau initial ? On déplace le système de fichiers ? Mais dans ce cas il faut le reformater à la bonne taille.

A+


Mokamicalement,
Florent Chabaud

Hors ligne

 

#9 13-09-2008 10:31:59

paipai62
MoKorateur
Date d'inscription: 05-07-2008
Messages: 407
Site web

Re: Projet de recherche sur OpenMoko

La mémoire n'est telle pas découper en "partions" ?

Une question: Ou est l'initramfs ? Je ne sais pas comment fonction "en internet" le kernel, mais tout les distrib que j'ai peu tester sur du x86* utilise un initramfs...
Comme cella se fait t'il que on n'en voir pas trace ?


Pardonnez-moi, je fait des fautes. Avec un correcteur d'orthographe, c'est juste moins moche.
1000 Excuses... Correction(s)? MP moi

Hors ligne

 

#10 13-09-2008 11:32:40

swap38
AdMoKostrateur
Lieu: Grenoble
Date d'inscription: 21-07-2008
Messages: 766
Site web

Re: Projet de recherche sur OpenMoko

khorben a écrit:

Je progresse (bien que trop doucement) sur RunningBear, l'OS créé par Bearstech notamment pour l'Openmoko.

Salut khorben

On peut avoir plus d'infos là-dessus (dans une nouvelle discussion) ?


"There's no place like ~"

L'APRIL a passé la barre des 5000 adhérents, mais l'effort continue. Soutenez l'APRIL

Hors ligne

 

#11 13-09-2008 12:05:18

khorben
Cool-Moko
Lieu: Berlin, Allemagne
Date d'inscription: 13-09-2008
Messages: 42
Site web

Re: Projet de recherche sur OpenMoko

paipai62 a écrit:

La mémoire n'est telle pas découper en "partions" ?

Une question: Ou est l'initramfs ? Je ne sais pas comment fonction "en internet" le kernel, mais tout les distrib que j'ai peu tester sur du x86* utilise un initramfs...
Comme cella se fait t'il que on n'en voir pas trace ?

Pour faire bref, il n'en a pas toujours été ainsi sur x86. Ce besoin est venu du nombre grandissant de drivers à supporter dans le kernel lui-même, avant qu'il ne puisse accéder au système de fichiers. En effet, il peut être aussi bien sur réseau que sur un contrôleur SCSI peu courant par exemple.

D'une part, il y a des limitations de taille pour le kernel dans le processus de boot (BIOS), et encore plus sur les médias amovibles (disquettes, CD-ROM...). Pendant longtemps booter sur CD-ROM voulait dire émuler une disquette de 2.88 Mo maximum.

D'autre part, une fois le bon driver chargé, c'est un gâchis de mémoire de garder les 150 autres. Les drivers contenus dans le ramdisk étant modulaires, seuls les nécessaires sont utilisés (avec un mécanisme de détection de matériel).

Sur un matériel comme l'Openmoko, cette ruse est inutile, vu que le matériel à supporter est déjà connu. Il faut au contraire réduire au maximum la quantité d'informations à charger, car c'est souvent plus performant ainsi.

Hors ligne

 

#12 13-09-2008 12:25:23

khorben
Cool-Moko
Lieu: Berlin, Allemagne
Date d'inscription: 13-09-2008
Messages: 42
Site web

Re: Projet de recherche sur OpenMoko

FlorentBL a écrit:

J'ai installé la debian et je confirme qu'elle implante bien la séparation des privilèges (on peut faire un useradd). Toutefois, j'ai l'impression que ce n'est pas très utilisé (tout semble se lancer en root également).

Bon à savoir. Je pense quand même que ce sera plus facile à réaliser que sur la distribution Openmoko, le choix des composants du "desktop" aidant.

Par ailleurs, je comprends du process que le noyau initial reste inchangé. Si je comprends bien la séquence de boot on a :
- u-boot qui se lance (on sélectionne boot sur sd-card)
- le noyau openmoko qui se lance
- montage de la partition root sur sd-card et boot linux
Donc quelle que soit la distrib, on a intérêt à upgrader le noyau OM.

Qqun peut confirmer ce point ?

Apparemment Debian ne fournit pas de kernel:
http://wiki.openmoko.org/wiki/Debian#Ho … oko_kernel

Donc il faut probablement s'en occuper soi-même.

Question subsidiaire : puisque le noyau et le système de fichiers OM sont contigus en mémoire (d'après ce que j'ai compris de ton talk vendredi à la Cantine) comment gère-t-on un noyau de taille différente du noyau initial ? On déplace le système de fichiers ? Mais dans ce cas il faut le reformater à la bonne taille.

Le partitionnement par défaut du Freerunner est comme suit:

Code:

+--------------------+
| u-boot             |
+--------------------+
| u-boot env         |
+--------------------+
| kernel             |
+--------------------+
| splashscreen       |
+--------------------+
| rootfs             |
+--------------------+

(le début de la mémoire flash étant en haut)

Les tailles sont fixes, et stockées dans l'environnement de u-boot (je ne sais pas comment est résolu le problème d'œuf et poule ici). Le kernel peut être de n'importe quelle taille, tant qu'il ne déborde pas sur le splashscreen. Idem pour le rootfs, qui lui ne peut physiquement pas déborder smile

Hors ligne

 

#13 13-09-2008 12:42:15

khorben
Cool-Moko
Lieu: Berlin, Allemagne
Date d'inscription: 13-09-2008
Messages: 42
Site web

Re: Projet de recherche sur OpenMoko

swap38 a écrit:

khorben a écrit:

Je progresse (bien que trop doucement) sur RunningBear, l'OS créé par Bearstech notamment pour l'Openmoko.

On peut avoir plus d'infos là-dessus (dans une nouvelle discussion) ?

J'ai créé cette discussion:
http://openmoko-fr.org/forum/viewtopic.php?id=217

Hors ligne

 

#14 13-09-2008 22:17:45

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

khorben a écrit:

paipai62 a écrit:

La mémoire n'est telle pas découper en "partions" ?

Une question: Ou est l'initramfs ? Je ne sais pas comment fonction "en internet" le kernel, mais tout les distrib que j'ai peu tester sur du x86* utilise un initramfs...
Comme cella se fait t'il que on n'en voir pas trace ?

Pour faire bref, il n'en a pas toujours été ainsi sur x86. Ce besoin est venu du nombre grandissant de drivers à supporter dans le kernel lui-même, avant qu'il ne puisse accéder au système de fichiers. En effet, il peut être aussi bien sur réseau que sur un contrôleur SCSI peu courant par exemple.

D'une part, il y a des limitations de taille pour le kernel dans le processus de boot (BIOS), et encore plus sur les médias amovibles (disquettes, CD-ROM...). Pendant longtemps booter sur CD-ROM voulait dire émuler une disquette de 2.88 Mo maximum.

D'autre part, une fois le bon driver chargé, c'est un gâchis de mémoire de garder les 150 autres. Les drivers contenus dans le ramdisk étant modulaires, seuls les nécessaires sont utilisés (avec un mécanisme de détection de matériel).

Sur un matériel comme l'Openmoko, cette ruse est inutile, vu que le matériel à supporter est déjà connu. Il faut au contraire réduire au maximum la quantité d'informations à charger, car c'est souvent plus performant ainsi.

Je confirme : sur un matériel figé comme l'openMoko, on peut même imaginer compiler un noyau monolithique (c'est-à-dire sans module) puisque tous les périphériques sont a priori connus. Cela poserait toutefois un problème pour le hotplug usb, mais à la limite, sur une plateforme qu'on voudrait sécurisée, cela peut-être un atout de limiter la connectivité usb au strict minimum que l'on souhaite pour éviter qu'on puisse, par exemple, monter automatiquement une clé USB.

Toutefois, je ne pense pas qu'on puisse se passer d'un noyau modulaire dans un premier temps, au moins pour la suspension. En effet, pour que le "réveil" des périphériques soit bien pris en compte, il faut que les drivers le prévoient. Or, souvent, ce n'est pas le cas : on a de beaux hook vides parce que le programmeur a mis cela en P2 dans sa liste de TODO. Dans ce cas, soit on remplit le hook, mais il faut encore que le matériel prévoit un état sleep. Soit on décharge le module et on le recharge au réveil : solution de facilité, mais bien utile wink

Au passage le support seLinux semble compilé dans le noyau ! Il y a un message d'erreur en début de séquence de boot. Tout cela me laisse à penser qu'un bon dégraissage serait utile. Encore faut-il constituer une plate-forme de dév pour pouvoir gérer correctement le noyau. C'est ma P1 dans ma TODO list smile


Mokamicalement,
Florent Chabaud

Hors ligne

 

#15 15-09-2008 16:16:04

Rodolphe
Mini Moko
Lieu: Toulouse
Date d'inscription: 15-09-2008
Messages: 5
Site web

Re: Projet de recherche sur OpenMoko

Concernant la sécurité globale de la distribution Openmoko, à ma connaissance, à l'heure actuelle, tout est exécuté en tant que root. Aussi d'après ce que j'en ai vu, ce n'est pas une contrainte de fonctionnement, c'est juste une commodité de développement.

Je vois qu'il y a dans cette discussion des gens expérimentés en sécurité, j'imagine donc qu'ils auront l'habitude de ce genre de situation et que l'on va pouvoir accepter ce constat sans s'émouvoir...
Bien sûr, plus on va laisser ce statu quo s'installer, plus il y aura des difficultés plus tard pour implanter une véritable séparation des privilèges et avoir une configuration système a peu prés propre d'un point de vue sécurité. (Sans parler d'aller plus loin.) Il y aurait certainement donc un travail à faire dès à présent pour implanter une bonne configuration par défaut de la sécurité de la distribution Unix exécutée sur le moko, sachant que ce sera probablement dans un contexte un peu original (celui d'Openembedded par exemple).
(Je ne suis pas sûr qu'envisager de basculer vers une Debian soit vraiment une option réaliste - ça se discute sans doute...)

NB: A ma connaissance, la situation est quasiment identique sur toutes les distributions logicielles utilisées pour les téléphones portables (et peut-être même pour la très grande majorité des systèmes embarqués...sad). Dans le cas d'Openmoko, il s'avère juste que c'est assez facile de le savoir et que personne ne le nie.

Je suis à peu près sûr que ces travaux-là seraient accueillis favorablement par les développeurs. La difficulté c'est plutôt de les assurer et de les suivre, ce qui demanderait des moyens.

Cette activité de durcissement de la configuration par défaut de la distribution serait sans doute intéressante, mais ne constituerait toutefois sans doute pas vraiment un projet de recherche (quoiqu'une division de la DCSSI pourrait peut-être le prendre en charge? cool).

Qu'est-ce que vous envisagez pour proposer une activité de recherche? En ce qui me concerne, je vois quelques idées à creuser autour de:
- la séquence d'initialisation et la validation de l'intégrité du système (il me semble que l'initiateur de cette discussion s'est déjà pas mal intéressé à ce type de sujet wink);
- la spécification des fonctions de sécurité (sur un téléphone/GPS grand public, ce n'est pas si évident aujourd'hui) et leur IHM;
- la vérification statique de certains composants du système ou de son architecture (à mon avis, plutôt sous l'angle d'un exemple de système embarqué).

J'ai quelques contacts qui pourraient vous intéresser (tous à confirmer néanmoins). Avec Supaéro qui pourrait peut-être être intéressé à ce type de plate-forme sous l'angle de l'enseignement (mais il faut qu'un enseignant titulaire ait envie de s'y investir). Les laboratoires voisins pourraient certainement apporter des choses, mais d'après ce que j'en sais cela pourrait ne pas coller avec leur politique scientifique.

Hors ligne

 

#16 15-09-2008 22:57:13

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

Rodolphe a écrit:

Cette activité de durcissement de la configuration par défaut de la distribution serait sans doute intéressante, mais ne constituerait toutefois sans doute pas vraiment un projet de recherche (quoiqu'une division de la DCSSI pourrait peut-être le prendre en charge? cool).

Qu'est-ce que vous envisagez pour proposer une activité de recherche? En ce qui me concerne, je vois quelques idées à creuser autour de:
- la séquence d'initialisation et la validation de l'intégrité du système (il me semble que l'initiateur de cette discussion s'est déjà pas mal intéressé à ce type de sujet wink);
- la spécification des fonctions de sécurité (sur un téléphone/GPS grand public, ce n'est pas si évident aujourd'hui) et leur IHM;
- la vérification statique de certains composants du système ou de son architecture (à mon avis, plutôt sous l'angle d'un exemple de système embarqué).

J'ai quelques contacts qui pourraient vous intéresser (tous à confirmer néanmoins). Avec Supaéro qui pourrait peut-être être intéressé à ce type de plate-forme sous l'angle de l'enseignement (mais il faut qu'un enseignant titulaire ait envie de s'y investir). Les laboratoires voisins pourraient certainement apporter des choses, mais d'après ce que j'en sais cela pourrait ne pas coller avec leur politique scientifique.

Il y a plusieurs choses qui peuvent être envisagées. D'abord le cloisonnement entre les différentes applications, histoire d'éviter qu'un SMS vérolé puisse, par exemple, initier automatiquement une communication téléphonique. Il serait ainsi intéressant d'élaborer un modèle de contrôle d'accès des différentes applis pour voir ce dont elles ont besoin et uniquement ce dont elles ont besoin, puis de l'appliquer sur la plateforme OpenMoko.

Ensuite, on peut étudier l'adéquation entre ce modèle au niveau OS et le modèle de sécurité matériel : comment sont implantées les opérations de cloisonnement ? Quelle garantie d'intégrité ? Quelles fonctions matérielles sont disponibles ? Dans le cas de l'openmoko, il est clair, par exemple, que l'accès possible aux interfaces de débuggage matériel poserait problème sur un produit opérationnel, mais ce serait intéressant de voir en quoi le modèle est altéré.

Enfin, on peut également développer des applications sécurisées sur la plate-forme : chiffrement mémoire, VPN d'accès à distance, authentification à distance, etc. en s'appuyant soit sur du logiciel, soit sur les fonctions de la SIM, soit sur des émulations de TPM, etc.

Ce qu'il faut voir aussi dans un projet de recherche c'est que les idées peuvent venir des autres partenaires wink


Mokamicalement,
Florent Chabaud

Hors ligne

 

#17 16-09-2008 09:35:22

youshe
Fun-Moko
Date d'inscription: 06-08-2008
Messages: 73

Re: Projet de recherche sur OpenMoko

Décidément, ce sujet m'intéresse grandement smile Domage que je ne sois qu'étudiant...

Petite question qui me passe par la tête, le processeur dont on dispose de combien de modes d'exécutions ? S'il en a au mois deux, nous avons déjà quelque chose à explorer de ce coté là. Sinon, c'est bien domage de se priver de cette solution matérielle, peut être une amélioration à apporter aux releases matérielles futures...

D'un autre coté (je crois en avoir parlé un peu quelque part, peut être ici), le port de l4 me parait assez intéressant. L'architecture (peut être) idéale du logiciel sur un PDA serait à mes yeux quelque chose comme :
- micro-noyau l4 (?)
- serveur graphique minimal (pas besoin de grosses usines à gaz à la X11, qui de plus sont le plus souvent difficiles à vérifier d'un coté sécurité)
- port d'une JVM sur l4 (il doit y avoir une thèse qui se profile autour de ce sujet en allemagne)
- Développement d'applications au dessus de cette JVM

Une autre piste à rajouter pourrait être d'utiliser l'API openGL comme interface  (et pourquoi pas java+OpenGL) ?

L'avantage de cette approche, est d'une part, la sécurité apportée par les couches basses (l4 a été construit pour être sécure et est aujourd'hui très robuste) et d'autre part, même à haut niveau (JVM) la sécurité a été éprouvée. De plus, sur beaucoup de PDA/Téléphones déjà en commercialisation, on dispose d'une grosse batterie d'applications dont les sources sont disponibles en java. Et puis il ne faut pas oublier le nombre de recherches actives qui se font au dessus de java : approches par composants, Intergiciel, ... Objectweb aurait certainement des choses à apporter. Ah oui, autre point sympa : compatibilité avec androïd ?
Et pour finir, même au sujet des trolls qui tournent autour de java, je pense que la réactivité et la rapidité de l'ensemble n'a rien à envier aux solutions actuelles sur openmoko.

Qu'en pensez vous ?

Fred

Hors ligne

 

#18 16-09-2008 21:43:59

Rodolphe
Mini Moko
Lieu: Toulouse
Date d'inscription: 15-09-2008
Messages: 5
Site web

Re: Projet de recherche sur OpenMoko

En ce qui concerne Java, effectivement il y doit déjà y avoir pas mal de travaux sur la sécurisation des applications Java (notamment via l'utilisation  de techniques de confinement), mais compte tenu des choix techniques d'Openmoko, ce n'est peut-être pas la meilleure cible.
Android serait peut-être un environnement plus intéressant (ce qui n'exclut peut-être pas un Néo d'ailleurs comme plate-forme matérielle), mais moins ouvert (parait-il) au niveau des couches basses.

Au niveau d'Openmoko, les développeurs ont plutôt l'air de pencher vers Python comme langage de haut niveau; mais surtout, on peut envisager d'agir à bas niveau (noyau, démons, etc.). Est-ce un avantage ou un inconvénient, c'est à voir en fonction

Par contre, envisager L4, une couche graphique spécifique (non X11) et une JVM comme environnement, cela me parait un peu révolutionnaire. Je crains qu'on ait beaucoup d'obstacles techniques à lever avant même d'arriver au niveau actuel de fonctionnalités déjà offert par Openmoko (ou par Android).

Dernière modification par Rodolphe (16-09-2008 23:00:24)

Hors ligne

 

#19 16-09-2008 22:19:18

FlorentBL
Moko
Lieu: Paris
Date d'inscription: 09-09-2008
Messages: 13
Site web

Re: Projet de recherche sur OpenMoko

l4 c'est un peu le marteau-pilon wink
N'oublions pas que nous sommes en environnement contraint et qu'une couche dédiée à la virtualisation n'apportera pas forcément grand chose, sauf à imaginer faire tourner des noyaux séparés, mais là je crains le syndrome bochs 8)
Par contre, java peut être une solution à condition, là encore de vérifier l'adéquation des modèles de sécurité. Mais dans ce cas, on peut aussi carrément envisager d'enlever l'OS et de faire reposer la sécurité directement sur la JVM.


Mokamicalement,
Florent Chabaud

Hors ligne

 

#20 16-09-2008 22:51:02

Rodolphe
Mini Moko
Lieu: Toulouse
Date d'inscription: 15-09-2008
Messages: 5
Site web

Re: Projet de recherche sur OpenMoko

FlorentBL a écrit:

Il y a plusieurs choses qui peuvent être envisagées. D'abord le cloisonnement entre les différentes applications, histoire d'éviter qu'un SMS vérolé puisse, par exemple, initier automatiquement une communication téléphonique. Il serait ainsi intéressant d'élaborer un modèle de contrôle d'accès des différentes applis pour voir ce dont elles ont besoin et uniquement ce dont elles ont besoin, puis de l'appliquer sur la plateforme OpenMoko.

Ensuite, on peut étudier l'adéquation entre ce modèle au niveau OS et le modèle de sécurité matériel : comment sont implantées les opérations de cloisonnement ? Quelle garantie d'intégrité ? Quelles fonctions matérielles sont disponibles ? Dans le cas de l'openmoko, il est clair, par exemple, que l'accès possible aux interfaces de débuggage matériel poserait problème sur un produit opérationnel, mais ce serait intéressant de voir en quoi le modèle est altéré.

Enfin, on peut également développer des applications sécurisées sur la plate-forme : chiffrement mémoire, VPN d'accès à distance, authentification à distance, etc. en s'appuyant soit sur du logiciel, soit sur les fonctions de la SIM, soit sur des émulations de TPM, etc.

Ce qu'il faut voir aussi dans un projet de recherche c'est que les idées peuvent venir des autres partenaires wink

Nous l'exprimons différemment, mais j'ai quand même l'impression qu'il y a beaucoup en commun dans les problématiques que nous identifions.

Au niveau du cloisonnement, j'aurais envie d'agir dès à présent sur la configuration Unix, par exemple en définissant des comptes techniques d'exécution pour les services réseaux (ssh, x11, dhcp, etc.) voire l'utilisation de chroot si c'est possible (comme sur la plupart des distribs. récentes ou avec la séparation des privilèges popularisée par OpenBSD), . C'est assez simple finalement, mais comme cela n'a pas encore été fait dans les distributions Openmoko... (NB: A vérifier pour Qtopia d'ailleurs.)
Effectivement, ensuite, il faudrait peut-être étendre cette approche aux différentes applications - si cela a un sens car un téléphone n'est pas à proprement parler un système multi-utilisateurs (?). Si des machines virtuelles sont présentes, il faut les prendre en compte sans doute; mais il n'y en a pas tant que cela pour l'instant (Java va bien finir par montrer son nez un jour).

La modélisation du contrôle d'accès va avec tout cela. Il faut aussi noter que l'utilisation assez importante des services DBus au niveau du middleware pourrait obliger/permettre de prendre le contrôle d'accès sous un angle original via le contrôle d'accès aux fonctions des API DBus.
(Est-ce d'ailleurs aussi là que l'on peut envisager un niveau de vérification formelle puisque DBus a l'air de régir toutes les interactions importantes entre les applications - avec un niveau de granularité assez élevé?)

Au niveau de la sécurité du matériel, la connaissance complète de la plate-forme offre certainement des possibilités pour les vérifications d'intégrité et la validation de l'implémentation, je suis tout à fait d'accord. Vous serez sans doute intéressé d'ailleurs par les projets actuels des développeurs pour les versions suivantes du matériel GTA04. D'après ce que j'ai compris, ils étudient l'introduction d'un deuxième processeur, trés basse consommation, à la fois pour avoir un mode de veille à énergie minimale mais aussi pour arriver à une solution alternative à l'interface JTAG (encore plus flexible, idéalement sur USB). Au niveau de la validation du matériel d'un point de vue sécurité, cela risque de changer la donne; mais cela pourrait peut-être offrir des opportunités nouvelles. (Voir ce fil de discussion sur la mailing list hardware pour plus d'infos, et notamment ce message.)

En ce qui concerne le développement d'applications orientées vers la sécurité sur ce type de machine, tous les sujets listés me semblent intéressants (VPN, auth., etc.). En montant vers des fonctions de plus haut niveau, il faudrait d'ailleurs voir si on ne pourrait pas offrir un socle plus protégé à des fonctions du type de celles qui ont popularisées le Blackberry (accès à des messageries distantes, des Intranet, etc.). Il y a aussi des études relatives à la monétique du côté de FranceTelecom non? (Vers Caen si j'ai bonne mémoire.)

Mais globalement, j'aimerais bien voir aborder moi la question de la spécification des besoins de sécurité sur un matériel comme celui-là, qui est à la fois: téléphone GSM, PDA individuel, navigateur Web portable, récepteur GPS et réceptable d'une carte à puce (au moins). Cela combine des problèmes de vie privée, de sécurité système, de télécommunications et de sécurité applicative d'une manière assez spectaculaire. (Et n'imaginons même pas le cas où le matériel en question est entre les mains d'un porteur détenteur d'une habilitation de haut niveau. wink) Pour un peu, cela détronerait même le NSS d'un A380 (non, quand même)...
Je suis tombé l'année dernière sur un projet de recherche européen qui abordait ces questions (Mobilife), mais ces travaux m'ont un peu laissés sur ma faim. J'aurais aimé plus de cas concrets, notamment du côté de la protection (déformation professionnelle j'imagine).

Par contre, je vais avoir du mal à envisager tout cela dans un cadre professionnel au niveau de la protection sociale (à moins de viser tout simplement la sécurité des Blackberries comme toute entreprise normale); même si cela colle certainement à la problématique du mastère où j'interviens à l'occasion (mais de manière mineure). Il y a des étudiants qui vont être déçus sad ... à moins d'arriver à rassembler d'autres partenaires. Des pistes?

Dernière modification par Rodolphe (17-09-2008 11:29:24)

Hors ligne

 

#21 16-09-2008 23:04:08

Rodolphe
Mini Moko
Lieu: Toulouse
Date d'inscription: 15-09-2008
Messages: 5
Site web

Re: Projet de recherche sur OpenMoko

FlorentBL a écrit:

[...]
Par contre, java peut être une solution à condition [...]. Mais dans ce cas, on peut aussi carrément envisager d'enlever l'OS et de faire reposer la sécurité directement sur la JVM.

C'est là à mon avis qu'il vaut mieux essayer de contribuer à la sécurité au niveau d'Android je pense (où la totalité des fonctions sont offertes sur une base Java).

Dernière modification par Rodolphe (16-09-2008 23:06:03)

Hors ligne

 

#22 17-09-2008 11:34:06

youshe
Fun-Moko
Date d'inscription: 06-08-2008
Messages: 73

Re: Projet de recherche sur OpenMoko

Une autre piste à laquelle je pense c'est celle suivit par la distribution xandros : interface simple avec une séparation des privilèges. Un utilisateur "user" par lequel l'utilisateur intervient et un utilisateur "root" pour lequel tout est permis (comme sur tout unix en fait). Rien n'est exécuté par root si ce n'est certaines applications où il est nécessaire de passer par sudo (de façon transparente et sans mot de passe par défaut).

En ce qui concerne d'autres partenaires, j'ai peut être trouvé un stage dans le labo verimag (http://www-verimag.imag.fr) qui s'intéresse aux systèmes embarqués, je pourrai leur toucher quelques mots de ce qui se trame peut être ici. J'ai rendez vous la semaine prochaine pour élaborer un sujet et il y a de grandes chances pour que cela tourne autour du neo et de la sécurité.

D'un autre coté, si je parlais de l4, c'est parce qu'il y a des recherches concernant l'utilisation du micro noyau sur de l'embarqué. L'architecture serait celle ci : matériel -> l4 -> jvm -> applis. Sauf erreur, le serveur graphique minimal existe déjà, mais je dis peut être des bêtises (cf tudos). J'en reparlerai plus tard si j'arrive à trouver le temps d'explorer et d'expérimenter d'une part et à quelque chose de potable d'autre part (sur GTA01, il y avait déjà eu un aboutissement, mais j'en ignore la maturité : http://wiki.ok-labs.com/).

Fred

Hors ligne

 

Pied de page des forums

Propulsé par FluxBB 1.2.20
Traduction par FluxBB.fr

Hébergé par :
Bearstech