1

Journe RIS Intergiciel et Sret de Fonctionnement

6 juin 2002

Sret de Fonctionnement dintergiciel CORBA:

caractrisation de services par injection de faute

Eric Marsden
<emarsden@laas.fr> 
Groupe TSF

LAAS-CNRS, Toulouse 




 2

Objectifs

Problmatique COTS pour les intgrateurs dintergiciel : besoin de

caractrisation

dvelopper une mthodologie dtalonnage de la robustesse

dun intergiciel
obtenir des mesures permettant de comparer diffrentes
implmentations entre elles
dvelopper des mcanismes dencapsulation qui amliorent la
robustesse du logiciel

valuer lefficacit de ces mcanismes



I Approche exprimentale base sur linjection de faute 



 3

Injection de faute

Mthode exprimentale de caractrisation de la SdF:

examiner les ractions du systme des conditions anormales
exercer ses mcanismes de detection derreur et de
recouvrement
obtenir des informations sur les modes de dfaillance
travaux prcdents sur les micronoyaux
lments dune campagne dinjection de faute:

quelles fautes injecter, ou, et quand (reprsentatitiv)?


quoi observer, et comment? 
quelle charge oprationelle (workload)? 



 4

O injecter les fautes?

process

process servant upperware

skeleton
client

stub
DSI
POA
DII
middleware

ORB core ORB core

operating system kernel operating system kernel underware 

host A host B
hardware 
network 



 5

Quelles classes de faute?

Simuler des fautes physiques transitoires :

corrompre le traffic rseau
bitflip dans lespace daddressage du courtier
Simuler des fautes du logiciel :
corrompre les paramtres dappels linterface du courtier
mutation de code dans la bibliothque, stub/skel, interfaces IDL
Simuler des fautes environnementales : 
problmes de ressource : manque de mmoire, coupure de

connexions IIOP 
tenue en charge : mesurer la dgradation de la performance en 
fonction du nombre et de la complexit des requtes 


 6

Cible exprimentale: COServices

Premiers travaux sur les services de noms et dvnement C ORBA :

interface standard : facile de comparer diffrentes
implmentations
point de dfaillance unique dans un systme base dintergiciel
pas vers la caractrisation dun courtier
Classification des modes de dfaillance :
crash du noyau

crash du service


hang du service : timeout sur une requte 
dfaillance de lapplication : lerreur se propage la charge 
exception C ORBA 


 7

Configuration exprimentale
workload

bind(), resolve(), unbind()

controller
target
logging corrupt resolve() service

database


exception application failure timeout

t=0 t=20s 
time
start experiment inject t=35 



 8

Modle de fautes

Bitflips et double-zro dans les requtes IIOP entrantes, avec trigger

temporel. On simule
fautes transitoires du systme de communication
propagation derreurs depuis les courtiers distants
interactions avec des clients malicieux (dni de service)
Un message peut tre corrompu diffrents niveaux :
couche transport : devrait tre dtect par la pile IP

niveau applicatif : dans les donnes encapsules


Reprsentativit: relev derreurs de communication [Stone & 
Partridge 2000] 



 9

Rsultats NS: modle de fautes bitflip

50

40

30

20

10

0
javaORB omniORB ORBacus ORBit 
ServiceCrash COMM FAILURE

ServiceHang BAD OPERATION
UNKNOWN MARSHAL 
OBJECT NOT EXIST
NotFound

InvalidName 


 10

Rsultats ES: modle de fautes bitflip

60

50

40

30

20

10

0
ORBacus Events TAO Events 


ServiceCrash BAD OPERATION
ServiceHang COMM FAILURE 
MARSHAL
OBJECT NOT EXIST

OBJ ADAPTER 
NoObservation


 11

Rsultats NS: par position

Analyse des modes de dfaillance suivant la position de la

corruption dans le message :

IIOP header operation arguments

0 8 16 32 48 64
OBJECT_NOT_EXIST 
MARSHAL
#\G #\I #\O #\P GIOP-version
byte-order
BAD_OPERATION


message-type
message-length service-context...
response-expected?
COMM_FAILURE 
object-key operation... requesting_principal ServiceHang 
ServiceCrash



 12

Conclusions

I mthode danalyse des modes de dfaillance dun service

CORBA, par injection de messages IIOP corrompus

met en vidence la diffrence entre spc et implmentation

technique portable : facile dajouter une nouvelle cible
mthode non intrusive
modle de faute limit


I Ajouter un checksum niveau applicatif GIOP






 13

Perspectives

tudier limpact du systme dexploitation sous-jacent sur la

robustesse
effet de la charge rseau et machine sur les modes de dfaillance
amliorer les observations : mesurer la latence de dtection
derreur
dvelopper des mcanismes dencapsulation pour les fautes
identifies
travailler sur dautres cibles et dautres modles de faute :

bitflips en mmoire


erreurs de ressources

tenue en charge

mutation de code



 14

Reprsentativit des fautes

Article de Stone et Partridge, SIGCOMM 2000 :

un segment TCP corrompu sur 30000
checksum TCP de 16 bits complment un
taux derreur rsiduel (non dtcts) de 1 par 3.3TB
soit toutes les 80 heures sur un LAN 100MB/s satur
Sources des erreurs :
matriel : cartes rseau, routeurs 
logiciel : piles de protocole des noyaux



I TCP est suppos fiable, mais ne lest pas 100% !



 15

Rsultats: autres observations

injections dans le champ longueur de la trame IIOP provoquent

des timeouts
bitflips des positions multiples de 8 sont souvent non dtectes
les bits de poids fort du byte order sont ignors. La corruption
des bits de poids faible provoque le crash du service.
dans certains cas, plusieurs conditions sont observes
(e.g., dfaillance de lapplication coupl une exception C ORBA)
les expriences sont essentiellement dterministes, malgr la
prsence de non-dterminisme dans le noyau et le rseau 







 16

Travaux antrieurs

Validation par injection de faute :

Ballista et corruption des paramtres dappels au courtier cot
client (Koopman, DSN 2001)
corruptions rseau ciblant un intergiciel spcifique sur CAN
(Koopman, FTCS 98)
ORCHESTRA: test de protocole par injection de faute
(Jahanian, University of Michigan)
loutil N-FTAPE : injection de faute dans les rseaux
(CRHC , UIUC)



Validation par test fonctionnel : 
CORVAL: tests de conformance du Open Group, et le projet 
CORVAL2 


 17

Rception de donnes inattendues

I Simule la prsence de clients dfaillants ou malveillants

envoyer des messages IIOP de type inattendu (eg
CancelRequest pour un request-id bidon)
envoyer des messages avec des exceptions inattendues
envoyer des messages ayant des service context bizarres
ngociation bizarre lors de ltablissement de la connexion IIOP









 18

Fautes de ressource

I Simule des fautes provenant de lenvironnement dexcution

coupure de session IIOP
manque de mmoire
disque local rempli
charge CPU leve
dfaillance de services C ORBA
On mesure ltanchiet de lintergiciel vis--vis de dfaillances du 
support dexcution. Si le courtier est robuste, il signalera ces


conditions lapplication, par exemple en soulevant des exceptions.





 19

Mutation de code

Simulation de fautes du logiciel. Les mutations peuvent tre

introduites diffrents niveaux :
code applicatif
code gnr par le compilateur IDL
bibliothque ORB
dans linterface IDL