4)* + -,.#&a bAci.unu.edu/media/publication/000/001/421/report398.pdf · Over the last decade, the importance of Free/Libre/Open Sou rce Software (FLOSS) ... International Workshop

�� ! "��#��$�� %��&$'(��)*��+ -,.#&��

/ �� 0�+1� 0��12�*��1��3�*��4�5 "��6879 / �:�<;=�>��@?"��#&��)��?"�BAC�EDFG��HG��$I "��J��LKM�N��&�O$P�

QSR%T!UVUXW4QSY Z\[L[^]

_ �&$@��8�*��* ��G�9� ��I "��#��$�� +��&$`'(�4)*�+�� -,.#&�a�bAc��

;=�>��!?"��#&��)4�d?"�BAC�EDFG��Hef�4�g�� ih&)jk�� T`lfm&npoqmsrBt@Z\[L[^]

usvxwygz�{}|�~�v��j� {}�P��ygv��a��y� ~��~�vP�.v�~ � ~�v� z��z�{}��.~�v��z*~�:{��L��z � {��{}z

� {��ygz��3�i�Cyg��j��^��~��*�C~��9�a~�vs�� *yE�C~��}�}{}��~>¡B¢g~�z��£�u��¤�g��

Preface

Over the last decade, the importance of Free/Libre/Open Source Software(FLOSS) has increased dramatically and the size and scope of the OSS confer-ence within which this workshop takes place is testament to that reality.

This volume contains the proceedings of the joint workshop: the firstInternational Workshop on Foundations and Techniques bringing togetherFree/Libre/Open Source Software and Formal Methods (FLOSS-FM 2008) andthe second International Workshop on Foundations and Techniques for OpenSource Software Certification (OpenCert 2008). All submitted papers have beenreviewed by at least 3 Program Committee members.

The aim of the workshop has been to bring together researchers fromacademia and industry, firstly, to study the question of FLOSS certificationand, secondly, to explore in the largest possible sense the question of how for-mal methods can be brought more successfully to bear on the open sourcephenomenon, and also how FLOSS can be brought more fully into the formalmethods community.

The organisers would like to take this opportunity to thank the contributors,the programme committee and all the referees for their interest and hard work.We leave to the reader the seeds the participants have sown.

Luis BarbosaPeter BreuerAntonio CeroneSimon Pickin

Conference Organization

Programme Chairs

Luis Barbosa

Peter Breuer

Antonio Cerone

Simon Pickin

Programme Committee

Bernhard K. Aichernig

Jesus Arias Fisteus

Roberto Barbuti

Vicky Bush

Jim Davies

Karim Djouani

Dan Ghica

Jesus M. Gonzalez-Barahona

Sotiris Ioannidis

Tomasz Janowski

Paddy Krishnan

Cristophe Morvan

John Noll

Jose Oliveira

Alexander K. Petrenko

Jorge Rocha

Walt Scacchi

Siraj Shaikh

Volker Stolz

Ralf Treinen

Joost Visser

Tanja Vos

David von Oheimb

Table of Contents

Open Source Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Simon Pickin, Peter Breuer

Four Compass Points in the Verification of the Linux Kernel . . . . . . . . . . . . . 10Peter Breuer, Simon Pickin

Incorporating Formal Methods in the Open Source Software DevelopmentProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Antonio Cerone, Siraj Shaikh

Certification of Technical Quality of Software . . . . . . . . . . . . . . . . . . . . . . . . . . 35Jose Pedro Correia, Joost Visser

Formal Methods for Open Source Components Certification . . . . . . . . . . . . . 52Alexey Khoroshilov, Vadim Mutilin

Extracting and verifying coordination models from source code . . . . . . . . . . 64Nuno Rodrigues, Luis Barbosa

Certification Infrastructure for the Linux Standard Base (LSB) . . . . . . . . . . 79Vladimir Rubanov, Denis Silakov

Keyword Index

API Standard . . . . . . . . . . . . . . . . . . . . . 79

Certification . . . . . . . . . . . . . . . . . . . . . . 79

Formal Modelling . . . . . . . . . . . . . . . . . 26

ISO-9126 . . . . . . . . . . . . . . . . . . . . . . . . . .35

Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Linux Drivers . . . . . . . . . . . . . . . . . . . . . 52

Linux Kernel . . . . . . . . . . . . . . . . . . . . 1,10

Open Source . . . . . . . . . . . . . . . . . . . . 1,52

OSS Development . . . . . . . . . . . . . . . . . 26

Pilot Project . . . . . . . . . . . . . . . . . . . . . . 26

Program Coordination . . . . . . . . . . . . 64

Program Slicing . . . . . . . . . . . . . . . . . . . 64

Reverse Engineering . . . . . . . . . . . . . . .64

Software Product Quality . . . . . . . . . 35

Static Analysis . . . . . . . . . . . . . . . . . . . . . 1

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Verification . . . . . . . . . . . . . . . . . . . 1,10,52

��

��! #"%$'&(�!)+*,�-$/.10%$�23&�4657468�9�:,;<8746=�4�87>?A@�BDCFEHGJILK+MNK+OQPR CTSNU RWVJXZY S\[WK+]F^_S\` R `3a R ]FMNEW^cbFbFb VJd K+e RfY PK+^ VhgAR `D]_S\`�iWjWkWlWl VhmDnpo brq

s+t,upvxwyu+zy{|u~}��,v��x��Js� m U7�DEJEpM�EW�ca�EWO�BD�yCTS Y e V|XZY S\[pK+]F^FSNCr��EW�c�hSN]FO�S Y eW� R O V �hSN]FO�S Y eW� R O��lW��ifI�I VJXZ�t|}��D{|vpsL��p�y�+��JvL��Jw

��L�x�+�6�D�J�+� b Y CF�DSN^�^F�DEW]FC�B R BHK+] �/Kc^F�DeWeWK+^_C RfY K+¡JCFK+] YLR MD^_K+]F[JSNU+KcEWB,K+] R CFS Y eS Y `DK+BHK Y `DK Y CFM\� R ^�CT�yKZMNS\¢pK+M\��U+K Y CF] R MHO�K+`DSN�DO£�!EW]�CT�yKZU+K+]FCFSN¤DU R CFS\E Y EW�hEWBHK Y^FEp�D]FU+K<U+E|`DK|G

¥§¦©¨_ª,«¬®ª,ª,¨_¯c°

±�² 0%=�5f³�"|8 ² "|´0|$µ0|$�0%¶-· ² � ²(² =��-574¸ ¹�º�»%ºJ¼�º|½hºh¾x¿�º�¾%¾%º�¾xÀ�º�¾xÁ%Â�Ã�³��-)x³A³�0 ²(Ä 4�46$A= ² 462A57"² )60%$'57³�4�Å��-$,=�ÆÇ*%4687$�46¶ ² "%=�87)�4�´�"%8�È,=�¶!$�46870 Ä �!¶!�-57�!4 ² º,0%$�2'0 ² 0%=�57³�"%8 ² ´É"%8� #0|$,·µ·%460%8 ²"|´ "%Ê�46$ ² "|=�87)64#¸ À%Á�º%À�¾xÂ ² "%´�5FÃZ0%874®Ê�87"JËf46)�5 ² Ã��!5f³ÇÊ�87"pÈ|4�$�0%$�)64 Ä "%57³ÇÃ��-57³��!$�¸ Ì�º%Í%Â�57³�4Å��!$y=�Æ3*%4�87$�46¶�¸ À%Ì%Â/0%$�2QÃ<�!57³�"%=�5A¸ Á%ÂFº�ÃZ4³�0pÈ%446Æ,Ê�4687�!46$�)�4�"%ć57³�4Ê�"|5746$,57�-0%¶/´É"%8®0%$�25f³�4�2��-Î#)6=�¶-57�!4 ² �-$�³�46874�$y5��!$'57³�4�)64�875f�!Ï�)�0|57�!"%$'"%´/"%Ê�46$ ² "%=�87)64 ² "%´�5FÃZ0%874y:

ÐhÑÒÐÔÓ�Õ�ÖØ×#Õ�Ù�ÚÒÚÒÖyÛ/ÜhÖØÝhÞß×#Ýà/Ö6ápâÙ�ã�Ö,àä×åÖ,æpç6èÒé/êDÙ�ç6èÒÝhÛ9�³�4� #" ² 5Z$�"%57�-)64�0 Ä ¶-4®0%$�2µÊ�" ²7² � Ä ¶-·#57³�4�2�� ² 57�!$�ë%=�� ² ³��!$�ë�)x³�0%870%)6574687� ² 57�-)®"|´ 0 ² =�)6)�4 ²7²íì´�=�¶ "%Ê�4�$ ² "%=�87)64 ² "|´É5FÃZ0%874�Ê�87"pËf4�)65�´�87"% î0#Ê�=�874�¶-· ² 570%57� ² 57�!)60%¶ Ê�"%�!$y5�"%´/Èy�!46Ãï� ²pð

ñ 9�³�4�870%Ê��!2'57=�87$�"pÈ%468�0%$�232��!È%468 ² 4�"%87�-ë%�!$ ² "%´��!5 ² )6",2�4,:ò/"y2�4�� ² 5F·yÊ��!)60%¶!¶-·Ç"%ó�46874�2'57"å0#È,� Ä 870|$,5�Ê�87"pË746)65 Ä ·µ #0%$y·Ç0%=�57³�"%8 ² º,57³�46$3)687�!5f�!)6� ² 462/º8746È,� ² 4623"%8ß0 ²7² 46 Ä ¶!462 Ä ·ô"%$�4�"%´/0A´�4�Ã£5787= ² 57462� #0|�!$,5f0%�!$�468 ² "%8ß2�4�È|4�¶-"%Ê�468 ² º Ä 46´É"|874Ä 46)6"% #�!$�ë��!$�)6"%87Ê�"%870%5f4�2õ0%5�5f³�0|5 ² 5f0%ë%4÷ö�"%Î#)6�-0%¶!¶-·,ø�:ùF5�� ² 57³�4�$ ² = Ä Ë746)657462ú"pÈ%468��!5 ²¶-�!´�4�5f�! #4�5f"�5f4 ² 5pºp)687�!5f�!)6� ² Øºp0%$�2#874�Èy�!46Ã Ä ·�57³�4� #0|$,·�)6"%$y5787� Ä =�5f4�8 ² 0%$�2#³�46¶-ÊL468 ² Ã<³�"0 ²í² ",)6�!0|574�Ã��-57³µ5f³�4ßÊ�87"pËf4�)65p:|9�³�4ß)�"y2�4ß� ² ö�"%Ê�46$�ø�º|0 ² 57³�4�$�0% #43ö�"%Ê�46$ ² "%=�87)�46ø ² =�ë ìë|4 ² 5 ² º ² "��-5c)�0|$ Ä 4 ² )60%$�$�4�2 Ä ·�0%¶!¶�Ã�³�"�)�0%874�57"�2�" ² "�:p9�³�0|5c"%Ê�46$�$�4 ²í² � ² �!$�³�4�8746$,5f¶!·=�$��!2��!8746)�5f�!"%$�0%¶Tº�³�"pÃZ4�È|4�8p: ± ¶-¶�Ã�³�"A #0p·ô)60%874�57"A)6"%$,5f87� Ä =�5f4�Ê�0|57)x³�4 ² Ã�³��!)x³ ² "%¶-È%4�0Ê�87" Ä ¶!46 �"%´�57³�46�!8�"pÃ�$'$�46462'"%8�Ï�$�2��!$�ë#)60%$'0%5f5746 #Ê�5<57"#2�" ² "�º Ä =�5�5f³�46�!8�)6"%$y5787� Ä = ì5f�!"%$AÃZ0%�!5 ² "%$A57³�4ßÊ�¶-4�0 ² =�874ß"%´L57³�4ßÊ�87"pË746)65pû ² 0|Ê�Ê�87"pÈ%462A #0%�!$y570%�-$�468 ² 0%$�2A2�46È%46¶!"%Ê�468 ²0 ² 57"#Ã�³�4657³�4�8��!5 Ä 4�874FË746)657462/º,0|)�)646Ê�5f4�2�º,"%8� #",2��-Ï�462�:

9�³�4ü5f=�87$�"pÈ%4681"%´�)6",2�4®� ² "%$�¶!·A=�$�)�"|$,5787"|¶!¶!462�ºD57³�4�8746´�"%874,º%�!$Ç57³�4 ² 46$ ² 4®57³�0%5157³�46874� ² 0|$�2ý)60%$ Ä 4'$�"þÊ�0%875f�!)6=�¶-0%8#2�46È%46¶!"|Ê� #46$y5#4�$yÈ,�-8í"|$� #46$y5#�! #Ê�" ² 4�2ý"%$ý57³�43 #0|$,·0|=�5f³�"%8 ² 0|$�2õ)6"%$y5787� Ä =�5f4�8 ² :cò/"%$y5787"%¶c0%¶!ÃZ0p· ² 46Æ,� ² 5 ² 0%5�¶!460 ² 5��-$ ² "%´�0%8�0 ² )+³�0%$�ë|4 ² �-$5f³�4 ² "|=�87)641)�"y2�4<0%87418746)�"%872�462å0|$�22�"y)�=� #46$,5f4�2È,�-0ü)x³�0%$�ë%4<¶-"%ë ² �!$57³�4 ² "%=�8í)641)6",2�4)6"%$y5787"%¶ ² · ² 5f4� ÿ= ² 462 Ä · 5f³�4' #0|�!$,5f0%�!$�468 ² 0%$�2ý2�46È%46¶-"%Ê�4�8 ² º/= ² =�0|¶!¶!· ò � �Ô¸!¾+Ì%Â�"%8��= Ä È%468 ² �!"%$�ºy0|$�2ô57³�4ü87460 ² "%$ ² ´�"%8<5f³�" ² 4ü)+³�0%$�ë%4 ² 0%874ü2�",)6=� #4�$y57462ô�!$ô57³�4ü4�Æy5746$ ² �!È|4

� ��

�! �"$#% &('*)+ �,-�+./&0 1'*,�#$24305242 #%�! �26�! 17()+#$"%#% 89"$#%2 : 2<;/=>#%?�#%2<;@)! �,-,�#$24305242 #%�! 1A/�+)+B ,2=>C#%3�CD)+3030�+7(.)+ FE(: C&G.B ��H�&030:I,&0J+&0"%�+.7(&0 F:K)+ ,D7()+#% �: &0 �)! �30&�L�MNJ+&0 D#% D)O.�B �<H�&P30:=>#$: CQ�+ "%ER)-24#$ �8+"$&*7()+#% Q)+5: C�+B(.�"$5�2()130"%#$&0 F:(30"%)+2 2(�+S�5�2 &0B 2�;T: C&*,�&0J+&0"%�+.7(&0 F:=>#$"%"UA/&(,��3P57(&0 F: &0,1A�EV: C&(C#%2 : �+B EV�!SK3WC)+ 8+&026B &030�+B ,�&0,-#% 1:�C�&XSYB &0ZF5&0 F:[.5�A"%#$3B &0"%&0)+2 &02\: C)+:>7O524:>)!3P30�+7(.)+ �ED)(245303P&02 2 SY5"]�+./&0 92 �+5B 3P&[.B ��H�&03P:^L

_ �<=K&0J+&0B<;/: C&(B )!.�#$,1:�5�B �<J+&0B[#%7(."%#%&02[: C)+:[30�F,&0àA)+2 &0,130&0B : #%b30)+: #$�+ 1#$26#$ �C&0B `&0 �: "%ED)(,#%c(305"%:>.B �+24./&030:>A/&P30)+52 &'edI "%EX)f2 #% 8+"$&�J+&0B 2 #%�+ g�+Sh:�C�&\3P��,&�SiB �+7j)O2 #$ �8+"$&�,)+: &\)+ ,k: #$7(&�30)+ gB4&0)+"$#%2 : #%30)+"$"%EA/&630&0B4:�#%b&0,9=>#%:�C�#$ 9)(2 5�A2 : )+ �: #%)!"l:�#%7(&[.@&0B #%��,m;�24)<ED)(E!&P)!B<L

n C&1.B ��H�&03P:*30�F,&1A�)!24&17(�<J+&029�+ o#$ �&0pF�!B )+A�"$Eq7(&0)+ �: #%7(&�;K24�Q: C&PB &1#$29)r7()<H �!BZ�5�&02 : #%�! f)+:l�! �30&N�<J+&0BT&0J+&0 f:�C�&N524&0Si5�"$ �&02 2T�+SF30&PB : #$b�30)+:�#%�+ T;s8+#$J+&0 f2 5�3�Cf)\30�+ 2 : B )+#% �:<Lt :67()<EuA/&(245..@�!24&0,v:�C�)!:f)! v)+30: #$J+&g.B ��H�&03P:67()<EuC)<J+&g)9B &0"%&0)+2 &g30EF30"%&(�+SI)+A/�+5:)97(�+ F:�Cm;h)!:f7(�+2 :<;h2 ��! �"$E-)+:f7(�!24:6�+ �&g#$ w:�=K&0"%J+&gB &0"%&0)+2 &P2f=K�+5"%,v&PJ!&P v&0J+&0BfA/&30&0B : #%b&0,m;/)+ ,1: C&("%)+:�&024:[3P&0B : #$b�&0,1J+&0B 2 #%�+ 1=K�+5"%,1�+ 1)<J!&PB )+8!&(A@&X24#$pu7(�! F: C26)+ ,2 #%pkB &P"$&P)!24&02yxi)+ ,92 #%pD?� ��<=> *JF5"% &0B4)!A�#$"%#%:�#%&02<;z./&0B C)+.�2<{m�+5:>�+ST,�)!: &�L

n C&PB &D7()<EvA/&|)u52 &|#$ }30&PB :�#%SiEF#% 8u)+"$"I: C&|30�F,&|)!:y)u24./&03P#$b3|J+&0B 2 #%�+ R#%2 245&0,=>#$: C-)|2 ./&03P#$b�3y�+./&0B )+: #% 8|2 EF2 : &07~J+&0B42 #%�! -�+SN�T#$ F5p];�Si�+B�&Pp�)+7(."%&�;�#%S�#$:�=K&PB &y./�+2 `2 #%A"%&1xY: C&0B &|)+B &|C�5� ,B &P,2X�!S\7(#%"%"$#%�+ 2X�+S\"$#% &02X�+S\30�F,&|#$ })u24#$ �8+"$&|,#%2 : B #%A5: #%�! m;#$ *7()+ �Ek,�#$�@&0B &0 F:�"%)! �8!5�)+8!&P2<;�)+ ,*7()+ �Ek,�#$�/&PB &0 F:�30�+7(.#%"$&PB 2>52 &P,T{ ;�A5:�: C�&0B &[)!B &)!"%2 �DCF5 �,B &0,�2G�+SU,�#$�/&PB &0 F:�,�#$24:�B #%A5�: #$�+ 2�Lm�T�+ �30&0 F:�B )+: #% 8D�+ V)D2 #% 8+"%&w�aC)+B ,�&0 &0,��,#%2 : B #$A�5: #$�+ O)+ ,O30&0B : #%SiEF#$ �8�#%:�2m30�F,&K)!2mA/&0#% 8GSiB &0&KSiB �+7e: C&K#%7(./&0B SY&030: #$�+ �2T,�&0: &030: &0,A�Ey: C&\30&PB :�#%b3P)!: #%�+ g.B �F30&02 2�7()<EyC�)<J!&\J<)+"%5&\: �6)6.)+B : #%305"%)+BN)+ ,g./�+2 24#$A�"$EyB4)!B &Pb&0,7()!B ?+&P:^;<A�5:N �+B 7()!"�52 &PB 2U#% (8+&0 &PB )!"�=>#$"%"7(�<J+&>�+ (SiB �+7�: C)+:U,�#$24:�B4#$A5�: #$�+ ()+2N2 �F�! )!2\#%:>A/&030�+7(&02\�+5: ,)+: &0,T;F=>C#%3WC*=>#%"$"]A@&[7(�+B &[�+B>"%&0242>#%7(7(&0,#%)+:�&P"$EFL

� �+B &P�^J+&PB<;F &0=oJF5"% &PB )!A�#$"%#%:�#%&02�;F5 �?� �<=> 9)+:>: C&6:�#%7(&6�!Sm30&PB :�#%b3P)!: #%�! m;F=>#%"$"]A/&30�+B B &030: &0,}#% }"%)!: &0BXJ+&0B 2 #%�+ 2X�+S\: C&|2 �+Si:�=I)!B &F;l=>C#%3�C}B4&0 ,�&0B 2X:�C�&|7(&0)+ #% 8+Si5�"$ �&02 2)! �,95: #%"$#%:�ED�+S�30�+ �: #$ F5#% 8g: �g52 &6: C&6�+"%,9A5�:>3P&0B : #$b�&0,92 �+SY:�=I)!B &f7(��+:\'(#%:\=�#%"%"]A/&30&0B : #%b&0,*�+ "%Ek)+2�C�)<J�#% 8XA@&0&0 *SiB &P&��+ST?� ��<=> |JF5"% &PB )!A�#$"%#%:�#%&02>SYB �!7�: C&[:�#%7(&[�!ST: C&30&0B : #%b30)+: #$�+ w)+ ,w: C&kSi)+30:f�+S�: C&k7()+:�: &0BO=>#$"%"�A/&k: C)+:f#%:f#$2OJF5"% &0B )+A"%&k: �� &0=>"%E,&0J+&0"%�+./&0,9)+:�: )+3�?F2<L

��e�O�T�V�6�m�<�N��P�V��X�F�<�0��m��0��

�m&0B : #$b�30)+:�#%�+ 97O52 :> ��+:��+ �"$ED8+5)+B ,9)!8+)+#% 2 :<¡' n C�&y#$ �)!,�J+&0B : &0 �:�#% �: B �F,53P:�#%�+ u�+SN&0B4B �!B 2[:�C�)!:�)+B &y �+:�&0)+2 #%"$E�Si�+5 �,u#% u30�F,&yB &0`JF#$&P=>2>�+B>: &024:�#% 8/;

A5:>)+"%2 �()+8+)!#% 24:^¡' n C�&[,&0"%#%A/&0B )+: &[2 5�B B &0.�:�#%: #$�+52\#$ �2 &0B : #%�+ *�+STA�)!3W?k,��+B 2\#$ F:��(.�5A"%#%3[,�+7()+#% *2 �+SY:�`=K)+B &FL

t :|2 C��!5�"$,¢A@&u)+,�7(#$: : &0,¢: C)+:|: C&PB &-#$2*#% ,�&0&0,¢2 �+7(&-�+../�+B : 5 �#$:�E£SY�+B|: C&-"%)+:�: &0B:��w�F30305�B<;�)+:k"%&0)+2 :k#$ ¤.B #% 30#%."%&�LU¥#% 3P&�: C&�JF#%8!#%"%)! �30&V)! �,£2 ?F#%"$"��+S�: C&V)!.�.B �<J+&0,,&0J+&0"%�+./&0B 2m)+ �,O7()+#$ F:�)+#% &0B42m#%2m:�C�&KbB 24:T)+ ,y7()<H��+Bm,&PSi&0 �2 &K)+8+)+#$ �2 :m2 53WCO)+:�: &07(.�:�2�;

¦m§z¨�©�ªs«^¬��®�Ö¯/¨�±°�²�³�®!´�°�²�«^© µ¶$·N¶%¸N¹0º+»�¹0¼0¶%½<¾+¿À%¼>· Á¾+·N¹0ºFÂ¼>ÃYÄ º+ÅÆ¾6Á¾+¿¶%·�Ç�¾+À¹Pº!»F· Ä ¶$¿�Ç· ¼0ÄN· Á¾+·N¹0º+»F·�¾+¶%»¸�¾6Â¶%¸ È+Ç¶%¸ ¼0ÂÅ(¾!À%ÉK¾+Ä ¼(¸ ¼P¹0· ¶$º+»1· Á¾+·6¶$¸6Â�¶$Ê(¹0Ç�À$·6· º*Ç�»Â¼PÄ ¸ · ¾!»�Â1Å(¶$È+ÁF·[¿/¼(· ¾+Ë+¼0»1¶%»1º+»1·�Ä Ç�¸ ·[¿FÌ¾uÅ(¾+¶$»F·�¾+¶%»¼0Ä�Íl¶$»}½F¶$¼PÉÎº+Ã\¾uÏÄ ¼P½�¶%º+Ç¸X¼0ÐF¼0Å(ÏÀ%¾+Ä ÌvÄ ¼0¹0º+Ä ÂmÑlÒ�Á�¼DÈ+ºFº�Â}ÃY¾!¶%· Á}º!Ã\· Á¼Å(¾!¶%»F·�¾+¶%»¼0ÄU¾+À$¸ º[Á¾+¸�· º�¿/¼I· ¾+Ë+¼0»Xº!»X· Ä Ç¸ ·<Ñ^Ó�»yÏ�Ä ¾!¹P·�¶%¹0¼FÍP¶%·�¶%¸�Ç�»À$¶%Ë+¼0À%Ìf·�Á�¾+·�¾!»FÌfÉK¼0À%À$Ô¶$»F· ¼0»�· ¶%º!»�¼0ÂfÅ(¾+¶%»�· ¾+¶$»�¼0ÄTº+ÄlÂ�¼0½+¼0À%º!Ï@¼0ÄTÉKº+ÇÀ$ÂOÏ/¼0Ä Å(¶%·l¸ Ç�¹�Áf¾�·�Á�¶$»�È\· º\ºF¹0¹PÇÄ<Ís¿/¼P¹0¾+Ç¸ ¼º!¿�¸ ¹0Ç�Ä ¶$·�Ì6º+Äm¿�ÇÀ%Ë6¶$»y¾G¹Pº�Â�¼K¹0º+»F· Ä ¶$¿�Ç· ¶$º+»y¶%¸m¶%»y¶$· ¸ ¼PÀ$Ã�¾GÄ ¼P¾!¸4º!»yÃYº!Ä�Ä ¼�Õ ¼0¹0· ¶$»�ÈG¶%·^ÑFÖmºFÂ¼¹0º+»�· Ä ¶%¿Ç· ¶%º!»�¸U· º�· Á¼�×T¶$»FÇÐOË!¼PÄ »¼0À¾!Ä ¼�ÃYÄ ¼0ØFÇ¼0»F· À$ÌOÄ ¼�Õ�¼P¹0· ¼0ÂXº+»X· Áº+¸ ¼�È+Ä º+Ç»Â�¸U¾!À%º+»¼¿�ÌD×l¶%»�Ç�¸>Òmº+Ä ½<¾+À$Â�¸<ÍFÃiº+Ä>¼PÐ�¾+Å(ÏÀ%¼�Ñ

Ù ¼0½+¼0Ä · Á¼0À%¼0¸4¸<Ísº+ÇÄl¾+»¾+À%Ì�¸4¶$¸T¸ Ç¶%· ¼NÁ�¾!¸T¶%»6· Á¼�Ï¾+¸ ·lÂ¼0· ¼0¹P·�¼PÂ6Ï�Ä º!¿�À$¼PÅ(¸lÉ>Á¶%¹WÁ6Á�¾<½!¼À$¾+¶%»6Ç�»Â¼P·�¼P¹0· ¼0Â6¶%»f·�Á�¼NË+¼0Ä »�¼0À�¹0º�Â�¼NÃYº+ÄlÌ!¼P¾+Ä ¸l¾+·l¾\·�¶%Å(¼�Úi¶%»f·�Á�¼N¸ º+Ç�»Â6Â�Ä ¶$½+¼0ÄTÀ$¾<Ì+¼0ÄT¶$»Ï¾+Ä · ¶$¹0Ç�À$¾+Ä<Û¶$»fÏ�À$¾+¶%»f½�¶%¼0Éwº!Ãz¾+À%À�Ñ�ÜK»f· Á¼�ÃY¾!¹P¼Nº+Ãz¶%·<Ís· Áº+¸ ¼�ÏÄ º+¿�À$¼0Å(¸TÉK¼P»�·TÇ»Â�¼0· ¼0¹0· ¼0Â¿/¼0¹0¾+Ç¸4¼u»º+¿/ºFÂÌrÄ ¼0½F¶%¼0ÉK¼0Âq· Á¼u¹Pº�Â�¼V¾+Ï�¾!Ä ·|ÃiÄ º+ÅÝ·�Á�¼uº+Ä ¶$È+¶%»¾+ÀGÅ(¾+¶%»�· ¾+¶$»�¼0Ä<Í�É�Á�ºÅ(¶$¸4¸ ¼0Â-· Á¼(ÏÄ º+¿À%¼0ÅVÍ/Á¾<½F¶$»�È|¶%»¾+Â�½!¼PÄ ·�¼P»�· À%Ì�¹PÄ ¼0¾+·�¼PÂ-¶%·�¶%»-· Á¼XÞ�Ä ¸ ·[¶$»�¸ · ¾+»¹0¼�Ñ/Ò>Á¼¹0º+»�· Ä ¶%¿Ç· ¶%º!»�¸k¶%»¤Ø�Ç¼P¸ · ¶$º+»¤ÉK¼0Ä ¼V¸ ºwÅ(¾!¸4¸ ¶%½!¼QÚY·�Á�¼�¸ º+Ç�»Â£¸4Ì�¸4·�¼PÅß¾!¸D¾wÉ>Áº+À$¼FÍU¶$»·�Á�¶$¸y¹0¾+¸ ¼FÛ>·�Á�¾!·O»�º+¿/º�Â�Ì-¾+Ï�Ï¾+Ä ¼0»F·�À%Ì1Á¾+ÂR·�Á�¼k¸4·�¾+Å(¶%»¾Vº+ÄOÂ�¼0¸ ¶%Ä ¼k· ºVÄ ¼0½F¶%¼0Éà¾+À$ÀKº+Ã¶$·<Í@Ï/¼0Ä Á¾+Ï�¸6»º+·6¼0½+¼0»1· Á¼(¾+Ç�·�Á�º!Ä6¾+»ÂvÅ(¾+¶$»F·�¾+¶%»¼0Ä�Ñ/Ò>ÁFÇ¸6¶%·6¾+ÏÏ/¼0¾+Ä ¸6¹PÀ$¼P¾!Ä6· Á¾+·6¾¿¾+ÂÀ%ÌX¶%»�· ¼0»F·�¶%º+»¼0ÂD¿Ç·K·�Ä Ç�¸ · ¼0ÂkÂ�¼0½+¼0À$º+Ï/¼PÄ�º+ÄKÅ(¾+¶$»F·�¾+¶%»¼0ÄKÅ(¾<Ì(¸ Ç¹P¹0¼0¼PÂg¶%»k¶%»<Õ�¼P¹0· ¶$»�ÈÅ(¾!À%ÉK¾+Ä ¼|¶$»F· ºu¾+»}º!Ï/¼P»}¸ º+ÇÄ ¹0¼|ÏÄ º�Õ�¼0¹P·yÂ¼0¸4Ï¶%·�¼|· Á¼|ÏÇ�¿À%¶$¹|¸ ¹PÄ Ç· ¶$»FÌ�Íl¾+»Â}· Á¾+·y¶%·Å(¾<ÌkÄ4¼0Å(¾+¶$»9Ç»�Â¼0· ¼0¹0· ¼0Â9· Á¼0Ä ¼6Ãiº+Ä>¸4º+ÅX¼6¹0º+»¸4¶$Â�¼0Ä ¾+¿À%¼[· ¶%Å(¼�Ñ

á ¸X¾uÅ(¾+·�· ¼0ÄXº+Ã\¶%»�· ¼0Ä ¼0¸4·^ÍT¸ º+Å(¼|º!Ã\· Á¼|Ï�¾!Ä4·�¶%¹0ÇÀ%¾+ÄXÏÄ º+¿À%¼0Å(¸XÂ¼P·�¼P¹0·�¼PÂ}¿�Ìvº+Ç�Ä¾!»�¾+À$ÌF¸ ¶%¸[¶$»-· Á¼X×T¶$»FÇÐVË!¼PÄ »¼0ÀUÉK¼0Ä ¼X¾<½+¼0Ä Ä ¼0Â-· º*Á¾<½+¼X¿/¼0¼0»-¹P¾!Ç�¸ ¼0Â-· ÁÄ4º!Ç�È!Á-È+À%º+¿¾+Àâ Þ�»Âu¾+»ÂVÄ4¼0ÏÀ%¾+¹0¼0ãD¼PÂ¶%·�¶%»ÈDº+Ï/¼PÄ ¾!· ¶%º+»¸<Í�É>Á�¼0»V¾|¹�Á¾+»È+¼y¶%»V· Á¼yÀ$º<ÉI¼0ÄGÀ%¼0½+¼0ÀmË+¼0Ä »�¼0À¶$»F· ¼0Ä Ãi¾+¹0¼P¸GÅ(¾+»Â�¾+·�¼PÂV¾D¹WÁ¾+»È+¼y¶$»u¾DÁ¶%È+Á¼0Ä�À$¼P½!¼PÀ�Ñ�Ó�·G¸4Áº+ÇÀ%ÂV¿/¼y»º+· ¼0Âu·�Á�¾!·�Å(¾!¶%»Ô·�¼P»¾+»¹0¼f¿�¾+¸ ¼0Â�º+»�¸4Ì�»F·�¾+Ð*¾!À%º+»¼f¶%¸�»º+·�È!¼P»¼0Ä ¾+À%À$Ì*¸ Ç¹P¹0¼0¸4¸ ÃiÇ�ÀlÉ>Á¼P»�¸ Ç¿�·�À%¼f¹WÁ¾+»È+¼0¸º!Ã�¸ ¼PÅ(¾!»F· ¶$¹0¸[¾+Ä ¼y¶%»�½+º+À$½+¼0ÂmÍ�¾!À%· Áº+ÇÈ+Á-¸ Ì�»F· ¾!¹P·�¶%¹X¹�Á¾+»�È!¼P¸�Å(¾<Ì�Ãiº+Ä Å~¾+»u¶%Å(Ï/º+Ä ·�¾+»F·Ï¾+Ä ·|º+Ãf·�Á�¼u»�¼0¹0¼0¸4¸ ¾+Ä Ì£Å(¾+¶$»F·�¼P»¾+»¹0¼FÍ�¾+»ÂTÍ�ÃYº+Ä|· Á¾+·|Ä ¼0¾+¸4º!»mÍ�¼0ÐFÏ/¼0Ä ¶%¼0»¹P¼0Â¢Å(¾!¶%»Ô·�¾+¶%»¼0Ä ¸yÈ+¼0»�¼0Ä ¾+À$À%Ì1· Ä Ì1¾+»ÂR¾+¹0¹0º+Å(Ï�¾!»FÌ1¾V¸4¼0Å(¾+»�· ¶%¹D¹�Á¾+»�È!¼DÉ>¶%·�ÁR¾u¸ ÌF»�· ¾+¹0· ¶$¹Dº+»¼Ñ0Ñ0Ñ�¹WÁ¾+»È+¶%»Èg·�Á�¼6»¾+Å(¼6º+Ãm¾(Ä ¼0¹Pº+Ä Â*Þ�¼0À%ÂTÍFÃYº+Ä>¼PÐ�¾+Å(ÏÀ%¼�Íz¸ º(· Á¾+·\¾!· · ¼0Å(Ï· ¼0Â�Ç¸ ¼0¸\º+Ã·�Á�¼\º+À$ÂkÞ¼0À%ÂgÉ>¶%À$À�¸ Á�º<É£ÇÏg¾+¸�¸4Ì�»F· ¾!¹P·�¶%¹\¼PÄ Ä º!Ä ¸�Ñ�×T¼0¸ ¸�¼PÐ�Ï/¼PÄ ¶$¼P»¹0¼PÂgÅ(¾+¶$»F·�¾+¶%»¼0Ä4¸�Å(¾<Ì»º+·>Ë�»�º<Éo· º(Ãiº+À$À%º<Éo· Á�¾!·>ËF¶$»�Â*º+ÃmÏÄ ºF¹0¼0Â�ÇÄ ¼FÑ

á ·N¾+»�ÌyÄ ¾+·�¼FÍ<¶%Ã/¾6Å(¾+¶%»�· ¾+¶$»�¼0ÄNº+ÄNÁ�¾!¿�¶$· Ç¾+À�¹0º+»F·�Ä ¶%¿Ç�·�¼PÄN¶$¸�¸ Ç¿F½+¼0Ä · ¼0ÂTÍ�Ï/¼PÄ Á¾+Ï¸N¿FÌ¿Ä ¶%¿/¼0Ä Ì�Í�º+ÄK¼PÀ$¸4¼G¶$¸�Â¼0À%¶$¿@¼0Ä ¾+·�¼PÀ$Ìg¿¾+ÂÀ%Ì(¶%»F·�¼P»�· ¶%º!»�¼0ÂTÍ�¶%·KÉKº+Ç�À$ÂD¿@¼GÏ/º+¸ ¸ ¶%¿À%¼G· ºO¼PÅO¿/¼0Â¾O¿�¾+¹�ËgÂºFº!Ä�¶$»F·�ºyº+Ï/¼P»D¸ º+Ç�Ä ¹0¼G¸4º!ÃY·�ÉK¾!Ä4¼�Ñ á È+¾+¶%»¸ ·I· Á¾+·<Í+· Á�¼Gº+»À%Ì(¾+Ï�Ï¾+Ä ¼0»F·KÂ�¼0Ãi¼P»¸ ¼¶$¸�äå á »D¾+Ç· º+Å(¾!· ¼0Â|¸ ¹0¾+»Dº+Ã]· Á¼�¸ º+ÇÄ ¹0¼G¹Pº�Â�¼�Í+Ä ¼PÏ/¼0¾+·�¼PÂD¾+·K¼P¾!¹WÁD¶%¸ ¸ Ç�¼Gº!Ãl·�Á�¼G¹0ºFÂ¼�Í�º+Ä¼P½!¼P»*Å(º+Ä ¼6ÃiÄ ¼0ØFÇ¼P»�· À$ÌFÍF¿�ÌD¾(· Ä Ç¸ · ¼0Â9º+Ç· ¸ ¶%Â¼6¾!È+¼P»¹0Ì�ÑÒ>Á¾+·>¶$¸\¼0¸ ¸4¼0»F·�¶%¾+À$À%ÌDÉ>Á¾+·>ÉK¼6ÏÄ º+Ï/º+¸ ¼6¾!¸\¾(¹0¼PÄ ·�¶%Þ¹P¾!· ¶%º!»9Å(¼0¹WÁ¾+»¶%¸ ÅVÑ

æ�ç�èeé6ê<ë]ì�í�îPî±ï<ðyñ�îPíFò¤óXíFê<ô0õ�ömì�ñ�ô0õ�ë�÷á »f¾+À$· ¼0Ä »�¾!· ¶%½!¼�Å(¼0· ÁºFÂº+À%º!È+Ì�ÉKº+ÇÀ%Â6¿@¼N· º\¹0¼0Ä · ¶$ÃYÌ�·�Á�¼NÏÄ ºF¹0¼0¸4¸lÃYº!Äl· Á¼�ÏÄ ºFÂÇ�¹0·�¶%º+»6º+Ã¹0º�Â�¼\¶$»�¸ · ¼0¾+Âgº+Ã@·�Á�¼\¹0ºFÂ¼\ÏÄ ºFÂÇ¹P¼0Âg¿FÌy·�Á�¼\ÏÄ ºF¹0¼0¸4¸<Ñ�Ò>Á¶%¸�¶%¸�¾6Å(¼0¹WÁ¾+»¶%¸ Åj¾+Âº+Ï· ¼0Â¶$»1· Á¼(ÏÄ º+Ï�Ä ¶$¼P·�¾+Ä ÌV¸4º!ÃY·�ÉK¾+Ä ¼X¶%»Â�Ç¸ · Ä ÌFÍ/É>Á¼0Ä ¼(Ó�ømÜe¾+»�Â-º+· Á¼PÄ[¸ · ¾+»Â�¾!Ä Â�¸6Ä ¼0È+ÇÀ%¾!· ¼·�Á�¼�¹P¼0Ä · ¶$Þ�¹0¾+·�¶%º+»(º!Ã/· Á¼>ÏÄ ºFÂÇ¹P·�¶%º+»(ÏÄ º�¹P¼0¸ ¸�Ñ<ù1¼�Â�º[»º+·U¿/¼0À%¶%¼0½+¼�¶%·U· º[¿/¼�¾+Ï�ÏÀ%¶$¹0¾+¿�À$¼

ú û�ü�ýþ�ÿ��þ��ýü �ü�� !�� #"��$!%��&'��$ ��(!��%��*)+��+,-��.��% +)*/��%!%0��1��%�2�� !%�3 �04&'��"6587�%�� 9&'�;:<�$��"�0�=��%�#��04>'>'?@>'&A/�� ?()%0��"B ��%C��>'0��&A��B&'�60D!%�� 0�&A>'=��%�#�6��B>A&'/��% ��?#E%F��6=�0+?/��G��&'/�>'�G��H�$ ��%��(�-0H!��% ��&AI$!%0��&'��J�$ ��(!%��-��H0��$��$�4 ��K04�K0H��&'��CB��H/��G"$�%��&' ��%"&A�2�� =��L��:�C�&'.(&'��C��1��:<��,-0� ��=�� !�04!M��N)*/��$�O&'�L,�&A>'>$/��&'=��&'/�>'��&A=��P�4�1�(EF��&A�3"$&AQ�!%�$>A�3��2!%��!%��&A.��:;0�=��("$�@&'�R,��&'!��R�� #!%��ST�� &'�%�#��"R!%�% ��&'I�!%0��&A��R=�0+?�4�P�% �0��$!%!%�%�1��:U��>'>A?V&'�W��!%��(��%X#��:6��W��$ �!%�@�1��:<��,-0� ��(E

Y�Z\[^]`_ba#c+d�eUf;g�h$d%e\i�jlk;a(c*mne\g�ao ��0��,-�� &A�30��p &'��"$�%��%�$"��%�#��% 1.(&'!%�q ��b��% �.#&A!��r,-��$>A"s/��b.��4>'��#��04 �?�0��tI$ �� pHu ��@04�$�4�� t��%�s�� 1!%�r�$ �� u �%!%�+E�F��C4�$0� �04�#��%�%�;��G�1!%0��6)%��0+?#)v��-wx&'�(�$Xty�� %>(�� !��9:U�4 ;y(��+,��B!%>'0��6��:z!��("$�9"��:<�%!��,��&'!��R=�0+?V/(?V��&'>A&'��%"R0��.#��>'�� 04/$&A>'&'��&'�%�3/#?V=b0�>',-0� ��(E q ��!%0��3��$>A"R/��p �1�%=�0��(��&'!%0�>A>'?V/�0��"/��K&'�{�� 0�!%��&A!�0�>P�� =��K��&A |&A�#�� 0�>P=��%!M��0��&'��=��|=�0+?2��"{��+,K04 �"$�|��$�D��?#�#��0�!%S��&'!��&'��!%��1?(�#��0�!%��&'!�04�$0�>A?#��&'��&A��=B�$!��}:U04�1�� @0��"}�1!%0�>A�%��/��% *E o ��s0R=�0�>A,-0� ��04��0�!�y2/��%!��4=��Ky#��+,��{04�$"V��t=��("$��K�� 04�$"�&P0��0�>'?(��"6)��0��K��$04>'>'?2>A�%0�"$�K��0b��0��% ��W��:6��@&'�W��@!%�#"��@��0��|!%0��W/��@>'�(��y��%"W:U�4 �&'�W0��{0��$��=�0��"W��(��>�E(~��$!��0{�$0��% ��}=�0+?�04>'��W&'��!%>'��"$�b�1�%=�0��(��&A!��%>'�%=��%�#��+)�:<�� @�%X#0�=��>'�()��0��@0WI�>A��0��"$>A�&A�B��1&A/$>A?}04!�!%�%��1�%"�0�C40�&'��/(?}��$�J!%�("$�J04:U�� H��JI$>A�J&'��%>':|��0��B/��%�%��!�>A��"6EnF��!M�J!%0��%�-0H�1�%=�0��(��&A!G0��0�>'?(�1&A�-&'�-��$�3��$>A?by#&'��"J��:P0��$04>'?#��&A�-��0��9=�0+?b&'�J�� &'��!�&A�$>A��!��+.4�� 0�>A>��#!%!%�$ � ��%�$!%�%�3�4:;�� /�>'�%=�E

q ��;�+.��% �&'��?�!��!�y��% V�A��M�O&A��W��=��b��X(��%�#�@0�>A ��04"$?�/��%&'��CW�$��%"}&A�}��&'�@!�04S��0�!%&'��?�/#?�&A��2!� ��%0�� *E��;�+.��% �&'��?�&A�J0�!%��=�=��% �!%&'0�>3��#��>�/$0��%"��4��0��%X#��%��1&A/$>A�.4�� &'�4�V��:��$�G��%�V�� !��G�1��0��"$04 1"s�}!��4=��$&A>'�% +)�C�!%!#E�F��N5 �-�� 04�� K04"$"J�1��%!%&'0�>AS&A�1�@"��=�0�&A�$ST/�0��%"}y#��+,�>'�%"�C��W��$�%&' s��!%��=��&'>A�� W&'�s�� "$�% @��W0�>A>'�+,�&'�@��W"��!%�!%�("$&A�$CR�� /�>'�%=��H,��&'!��0+.��%&' �� &'C4&'��H&'�}��&'C��% H>A��.4��>O!��4�$�� !%��H��$04��>'&'��%��4:L!��("$�(E$��?#��&'!%0�>;�$&A��!%�r��:L"��=�04&'��y#��+,�>'�%"�C��r=�&'C4�#�D/P�()$:<�� t�%X#04=��$>A�#)$��0��D��04�$"�0� �"��s>A&'/� �0� �?b!%0�>A>3�T!�>A��1�%��$0��9��$�3�%��%!��L��:P!%>'��&'��CH0�I$>A�3�$04�$"�>'�()*�� 9��0��L��>'&A/$ �0� �?W!%0�>'>H��=�04>'>'�(!��J�$ ��+.(&'"��%�D0V��&A�#��% D��V0J!M�(�$��yW��:O=��%=�� ?W��B�$�%0��6E� �%:U�% ��%�$!%�2��R��2I$>A�2��0��$"�>'�204:U��% H!%>A��1�204�$"�/��%:U�4 ��%�$�R�� %��%��%��!(En&A�&A>'>'�%C�04>-�U0��"R��% ��304�R0��0�!�yV.��%!�� 304C�0�&'��:<��,-0� ��#��E

�;�+.��% �&'��?�&'��1�%>A:G&A�b�� $ �&A�%��0� �?()604�$"�&A��b&A�$��0� �"��b0� ��{��r0�!%!%��&'/�>'�{�� %.#&A��,04�$"�:<�� D��0��D ��0��,K�B�$0+.4�r��VC��t04�t��+,�&A�D,K�4 �y#�t&A��"$�%��04&'>�)$,��&'!��=�0+?R/��0�!%!��%��0�/�>'�90��6�$0� ��x��:�04�B��%�H�1�� !%�9!��% ��&AI$!%0��&'��B�� (!��%��*Ev�D�+,-�%.��% +)%��-=��("$�%>�4:;&A�#��% �0�!%��&A��R��$04��%?V0� ��@:<��>'>A�+,�&'��C�,�&'��R��@wx&'�#��XJ�$ �� u ��!%��&A�� ,�&A�1�@,��0��,-�B��C�C��%�1�G0��D��0� ��G��:O0V.(&'0�/�>A�B!��% ��&AI$!%0��&A�� 1�(!%��D/��%!�04�$��B��%?W�$0+.��B/��&'>'�G��02>A��.4��>x��:;�� $��3"��&'��H!%>'��%"��0�� H��:;��&A G�+,��!%�("$�(EK� o �$�2,-0��!M��%�G��,-0��!M��% ��1�H&A�-0�=�0�X#&A=��$04�9��C��#�L��H/��3��0�y��%�2&'�#��H0�!%!��4�$�(�+)40��"2��G!%�% ��&'I�!%0��&A�� #!%�%"$�� -�1��>'"B/P�4��r/��-��6)�0��"r!%��"��$!%��%"6)�&'��1�4:U0� ;0��;&'�;&'�;0��=�0��"6)��1&A�$C�4�P�%�W�1�� !%��:<��,-0� ��#��>A�*E

F��"$�%�%";)#��$�@!%�� &'I�!�04��&'��W�$ ��(!��%��3��>'"R/��@/$��"$>A��"W&'�(��0

�;�z�� v¡N¢�£�¤��B¥��£§¦�¨�©�¤4ª�¦�¨�¡N� «

¬�1®4¯U°�±-²�³�´@µ$®+±�¶�·'®4²�µ�®s°�¸�²�°b¹�®�°�´�¶(°�ºA²�·|»�´%³�°�ºA¼$»%²�°�´�´%b»�²�¶�³�½�¶�°�¸�´{°�®#®4·'�´�°b®+¾4´�³b°�¸�´%º'³b»�®(µ$´{°�®s°�³�¿�²�¶�µ´%¶�1½�³�´r°�¸$²4°tºA°t±�ºA·'·;¹$²41+À$Á�¸�²�°D1¸�®�½�·'µ�¶�®�°D»%®�Â�¹�³1®4Â�º'�´r°�¸�´r»%´�³�°�º'¼�»�²4°�º'®4¶s¹�³�®#»%´%�ºA°��´�·A¯�Ã4Ä�´%»�²4½$�´GºA°�-¹�³�®#µ�½$»%°9ÂB½$�°9º'¶J°�¸$´3´�¶�µJÂ�´%³�´%·'¿b»%®�¶$�º'�°9®�¯n²H»%´�³�°�²�º'¶J¾4´�³��º'®4¶J®�¯°�¸$´�»%´�³�°�º'¼�»�²4°�º'®�¶�¹�³1®(»%´��L¸$²+¾(º'¶�Å�Ä�´�´%¶�²�¹�¹$·Aº'´%µ2°�®�²@»�´%³�°�²4º'¶2¾4´�³��º'®4¶2®�¯�°�¸�´3»%´%³�°�º'¼�´%µ�®�¯<°�±-²�³�´�²�¶�µÆ®�½�³V¾#ºA1ºA®�¶Æº'V°�¸�²�°V1®4½$³�»%´�»%®#µ�´�»%²�¶lÄP´�»M¸�´%»MÇ�´%µÆ²4Å�²�º'¶��°{²�Å4º'¾�´%¶¾4´�³��º'®4¶l®�¯@°�¸$´�»�´%³�°�ºA¼$»%²�°�º'®�¶l�½�º'°�´�Ä#¿�²�¶(¿�º'¶(°�´%³�´��°�´%µl¹�²�³�°�¿�°�®�1´%´�°�¸$²4°Jº'°Jµ�®#´%ºA¶$µ�´%´�µB¹�²��*Ã%²�;°�¸�´-²�½�°�¸�®�³;®�¯�°�¸�´-1®4¯U°�±-²�³�´-Â�²+¿@¸$²+¾4´K»%·'²4º'Â�´%µ;À%È$´%Â�²�¶(°�º'»%²�·A·'¿�Ä�²��´%µ²4¶$²�·A¿#�º'B1¸�®�½�·'µ�³�´%¶�µ$´%³B°�¸�´V»%´%³�°�º'¼�»%²�°�ºA®�¶�¹�³�®#»%´%1B¹$³�®(®�¯�²�Å4²�º'¶��°rÄ�´%º'¶�Å�¯<®#®�·A´�µ�Ä#¿»�¸�²�¶$Å4´�@®4¯9¾+²�³�º'²�Ä�·'´b¶�²�Â�´r²�¶$µ�»�®(µ$´r1°�³1½�»%°�½�³�´b°�¸�²�°tÂ�º'Å�¸(°@�½�»�»%´%�1¯<½�·'·'¿�Å�²4Â�Â�®�¶²��¿#¶(°�²�»%°�ºA»V²�¶�²�·'¿(1ºA*À�ÉK½$°B»%²�¶��´%Â�²�¶#°�º'»V²�¶�²�·A¿#�º'r²4·'�®�Ä�´J¯U®(®�·'´%µ�Ä#¿}�®�Â�´JÇ#º'¶�µ�®4¯x»%®(µ$´D»�¸$²4¶$Å4´�+ÊKË�¶V¹�³�º'¶�»�ºA¹�·'´(Ã��¹�·'º'°�°�º'¶�År¯<½$¶�»%°�º'®4¶$K½�¹Vº'¶(°�®�Ã�¯U®4³K´�Ì(²�Â�¹�·'´(Ã�µ�º'Í�´%³�´%¶#°¹�²�³�²�·A·'´%·O°�¸�³�´�²4µ$@±�¸�º'»�¸}´%²�»M¸sµ�®R²{¹P®4³�°�º'®�¶s®�¯-°�¸$´bº'¶(°�´%¶$µ�´%µ}±-®�³�Ç�®4½$Å4¸#°@°�®WÂ�²4Ç�´°�¸$´Jº'¶#°�´�¶(°�ºA®�¶�®�¯�°�¸�´V»%®(µ$´Jº'Â�¹�®��1ºAÄ$·A´V°�®�µ�º'¾(º'¶�´#À�ÎÏ²�³�²4·'·'´%·-°�¸�³�´�²4µ$B±K®4³�Ç#º'¶�Å�®�¶�²»%®�Â�Â�®4¶�²�³�´%²�®4¯DÂ�´%Â�®�³�¿�Â�²+¿�º'¶�¹�³�º'¶�»%º'¹�·'´Rµ�®}²�¶(¿#°�¸�º'¶�Å}²�°�²�·'·�À;Á�¸$´%³�´%¯U®�³�´W°�¸�´»%´%³�°�º'¼�»%²�°�ºA®�¶R¹�³�®#»%´%1��¸$®�½�·'µW´�¶�¯<®�³�»%´¬�»�®(µ�º'¶�Å2�°�²4¶$µ�²�³�µ�±�¸�º'»�¸r¯<®�³�Ä$ºAµr°�¸�²�°;Ç#º'¶�µr®�¯$�®�¯<°�±-²�³�´Kµ$´%�º'Å�¶6Ã�²�°;·'´%²��°Ï®4¶r°�¸�´KÅ�³�®�½�¶$µ�Ï°�¸�²�°;º'°;³�´%¶$µ�´%³�²4¶$²�·A¿#�º'�´�Í�´%»%°�º'¾4´�·A¿Vº'Â�¹�®��º'Ä�·'´(ÀÐ µ$ºAÅ�º'°�²�·x1ºAÅ�¶$²4°�½�³�´H¯U®4³G°�¸�´H°�´��°�´%µ��®�¯<°�±-²�³�´H²�¶�µ�°�¸�´H°�´%�°�º'¶�Å2¹$³�®(»%´��G�®�¯<°�±-²�³�´Â�²+¿}Ä�´JÇ�´%¹$°B»%´%¶#°�³�²4·'·'¿}²4°B°�¸$´J»%´�³�°�ºA¼�»�²�°�º'®�¶�1ºA°�´(Ã�²�¶�µ�²�¶#¿sº'¶#°�´�³�´%�°�´%µ�¹�²�³�°�¿}Â�²+¿»�¸�®#®��´D°�®r»�¸�´�»�Ç2Â�´%³�´%·'¿�°�¸�²�°K°�¸$´D»%´%³�°�º'¼�´%µV1®�¯<°�±-²�³�´DÂ�²�°�»�¸�´�K°�¸�´D�º'Å�¶�²�°�½�³�´D�°�®�³�´%µÑ ²�{µ�®#´%{°�¸$´�»�´%³�°�ºA¯U¿(º'¶�Å��®�¯<°�±-²�³�´(Ò�À Ð 1ºA¶$Å4·'´��º'Å4¶$²�°�½$³�´�Â�²+¿�ÄP´�½�1´%µ�Ó�®�º'¶(°�·A¿�ºA¶°�¸$´W�®�¯<°�±-²�³�´Wº'°��´%·'¯G¬}°�¸$²�°bº'+Ã;°�¸$´W»%´%³�°�º'¼�»%²�°�´W¯<®�³�°�¸�´W°�²�³�Å4´�°b�®�¯U°�±-²4³1´WÂ�²+¿�¸$²+¾4´Ä�´%´%¶R²�Ô�Ì#´%µR°�®�°�¸�´�°�²4³1Å4´�°��®�½�³1»%´�»%®#µ�´�²4·'³�´%²�µ$¿V�º'Å�¶�´%µR±�º'°�¸R°�¸$´@1ºAÅ�¶$²4°�½�³�´�®�¯;°�¸�´°�´��°�ºA¶$Å��½$ºA°�´(À Ð ·'°�´�³�¶�²�°�ºA¾�´%·'¿�²�Å�²�ºA¶;ÃL°�¸�´�²�½�°�¸�®�³V®�¯�°�¸�´�»%®#µ�´�Â�²+¿��º'Å�¶l¸$ºA{®+±�¶»%®(µ$´B±�º'°�¸�²V�º'Å�¶�²�°�½$³�´r®4Ä$°�²�º'¶�´%µ�¯U³�®�ÂÕ°�¸�´r»%´%¶#°�³�²4·Ï²4½$°�¸$®4³1ºA°�¿R°�¸�²�°D1²+¿(t°�¸�²�°D°�¸�²�°�®�¯<°�±-²�³�´2¸$²4HÄ�´�´%¶�°�´%�°�´%µ�²�¶$µ�»%´%³�°�º'¼�´%µ;ÃP°�¸(½$HÂ�²4Ç#º'¶�Å�°�¸$´2�®�½�³�»%´2»�®(µ$´�»�²�³�³�¿�º'°�®+±�¶W»%´�³�°�ºA¼�»�²�°�º'®�¶6À

Ë�°�º'H¹�®��º'Ä�·'´2°�¸�²�°�º'�1½�´%µ�»%´�³�°�º'¼�»�²4°�´%H»�®4½$·Aµ�ÄP´�³�´�¾�®4Ç�´%µ�±�¸$´%¶�ºA¶$�½$Ôb»�ºA´�¶�»%º'´%ºA¶�°�¸$´2°�´%�°�º'¶�Å�¹�³�®#»%´%1HºA°�1´%·A¯|²�³�´2µ�º'�»�®+¾4´�³�´%µ6Ãn³�´%Ö#½�º'³�º'¶�Å�²4½$°�¸�®�³�H°�®�³�´%»%´%³1°�º'¯<¿#ÃPÄ$½�°°�¸$²4°-¸$²�³�µ�·'¿b1´%´%Â�K²BÅ4®#®#µJº'µ�´%²B²�K²4·'·�»%´%³1°�º'¼�»%²�°�º'®4¶$-°�¸�²�°-²�³�´G¶$®�°-²4Ä$�®�·A½$°�´�·A¿�½$¹J°�®µ�²�°�´H1¸�®�½�·'µ�Ä�´H³�´%»�®4Å�¶$ºA×%´�µ�²�GÄ�´%º'¶�Å2¹P®41�º'Ä�·'¿{Â�º'�·A´�²�µ�º'¶�Å�ÀzØD´%¾�´%³�°�¸�´�·A´��+Ãz°�¸$´HºAµ$´%²®4¯L²J»�´%³�°�ºA¼$»%²�°�´B°�¸�²�°D¸�²�D²V¼�Ì#´%µ�°�ºAÂ�´B°�®V·Aº'¾�´(Ã$�²+¿W®�¶�´BÂ�®�¶#°�¸;Ã�º'D²V¹�®��º'Ä�º'·Aº'°�¿(À$Ë�°±-®�½�·'µW³�´�Ö(½�º'³�´�®4·'µR�®�¯<°�±-²�³�´�°�®�ÄP´@»%®�¶#°�º'¶#½�²�·A·'¿V³�´%»�´%³�°�ºA¼$´%µR¾(º'²�²¬�®�¶�Å�®�º'¶�Å�³�´%»�´%³�°�ºA¼$»%²�°�º'®�¶R¹�³�®#»%´%�ºA¶b±�¸$ºA»M¸b²t»�´%³�°�ºA¼$»%²�°�º'®�¶bÂ�²�¶�²�Å4´�³O®4¶b°�¸�´|½$�´%³+Ù OÂ�²�»�¸$ºA¶�´�»%®�¶�¶�´�»%°�´%µb°�®t°�¸�´|¶�´�°Ï²�¶�µ®4Ä$°�²�º'¶�´�µW¶$´%±Ú»%´�³�°�º'¼�»�²4°�´%3¯<®�³�°�¸�´ Ñ µ�º'Å4º'°�²�·��º'Å4¶$²�°�½$³�´%3®4¯+Ò;ºA°��´�Ì(º'�°�º'¶�Å��®�¯U°�±-²4³�´#ÀÛ�Ü\Ý^Þ`ß-àná�â$ã\ãUä#åNæDç�è(á�é;ê%è#ëlìbè#í+ê�îUï;á�â$ê%î\à�ðlñ;è(í*ònî\á�èÉK½$°t»%®�½�·'µs²�¶(¿�»�´%¶#°�³�²�·Ï»�´%³�°�ºA¼$»%²�°�ºA®�¶s¹�³�®#»%´��@¸�²�¶�µ$·A´b°�¸�´b¸#½�Å�´b¾�®4·'½�Â�´b®�¯9³�´%»�´%³�°�ºAó¼�»%²�°�ºA®�¶�³�´%Ö#½�´%�°�G¯<®�³3®�·Aµ�²4¶$µRµ�º'Í�´%³1´%¶(°3¾�´%³�1ºA®�¶�G®4¯Ï°�¸�´�ÂB½$·A°�º'°�½$µ�º'¶�®�½�G¹�³�®*Ó�´%»�°�GºA¶´%Ì(º'�°�´%¶$»%´(Ê3ØG®�°�±�º'°�¸$®4½$°�¸�´�·A¹;À#ÉK½�°

ô õ(ö$÷�ø8ù�ú*ø�û�ü�û�ý�÷�ö þGö�ÿ�� !��"$#%"�& & �$'(��)��*�� +��"�� ,�-��.�� /��102�*��,��,"1��*��-��$34�5�,��-&5��+��-��.6-78)�"��9':��-&5�;�2��5�1�� +��"��5��;��<�- ��=��)-�>��-��5�-!<�� 9��?��)-�8� �.�� -"��@#="��A��)-�8�-��0�& �5�B"��/& "��!��8� ��C��D�E��?F��G��)��B�� +��"��5��5�� &5?�3H'8)�� )I�5 B��"��"�&5& #<��-��"�� -"�& & #<� �.�� 5J��H6K �L�� L��M��,�-�� !NF�-��& �5O��M'8)�"��>�5 >��"��H�>0.#P��)��<�5�-�� #Q��R 7>SUT23V'8)�� )L��5�-"�&5& #P ��"�� >?F�� R �� L�� !�TW0��-��"�&5& #;��"�� %��)��)�"��'X"��YZ�� "��(��?F�- �"�&:��?["P��-��,��P��H�� 5!��(0H#L��)-�\��2��Y"�� !< �#H ��]��"��H��?F"��-��$^�3-��)-�>��#I"��_�-��.�� 9��?C"<��=��-��"��[�� A��"��#=��`"%��"�� A� �A��-&5��[ �� #.3a �"�?F�B?b��c��0- ��J$"��5��"��-�=��"��2�� !10H#��)��*�$'8��d��?��)-�:��"��)-�5�-�.6478)�� d� d�2�� 50-&5�*��5��)-��d�� 5�-!9 ��2��5"�&��#W)�"��-'X"��WNF'8)-�5�e)P��#.�-�� D� �� D�5�-�� D"��P��-�� $^`��D��-��& #W ��?F��'X"��"��- �?F��"��5��"�&:��e)��-�5fH�� WNb�� H�� "�&5& #g��>��& "�� (��?B"��(��#.�-��h ��"��\��"�Y��)�� H3H'8)�� )I�5 B �& �$'X��$^�6i�jlknm�oUp�q-r�s_t�uBqQv�s.wap�xlyUz�q�p�xlt�{}|~sHw$��xbz�s78)�� 9��)-��&5��!�#.3-'8)��_"��_� ?/� �9"�� J�� $3-'8� &5&U��"�O��=��)-�>�� +��"�� ;��H�� 9��YJ.� �"�!��A��"��5��"�&-"��C"�& "��!��8 ��"�&5�H6 K �A��)��B��"��.�� .3aJ��& ��H��"��#= ��"�� `0.#="��.��"�&"��-��)-��5��#<��?U�5��E��"��.�B��E��I �� ?F��'X"�� #H �� B ��-��)I"� B��)�� .�-�<O��&�3� �-"��e)��1'X��0\ ��J��$3.�d�5��?F�$�A0-��$'8 ��$3V�X�2��~�X��1��1 �� 1��.6�'X��& �\ ��J��1"� ",��"��)\��,��!��-��*�� *"��?F"�� &5� "��5��#<�5��",�� +��"�� \�-��.�� a6 K �,�E��"��.��& #"�& ��23�� X��5!�)H�X)��& �M!��-��"��[��H��50��-��5�� :?F��)��9�� X��>�-�� @#�"��X& "��!��9��Y'X"�� 9��)��=�� 9�5�-��2��"��_� �_��)��>��5+-��"�� _�-��.�� a3� ��)-�5�-!M'8)-�5�e)_)-"� ��H��-��g ��I?b"��"��& ��"� ��%�5�g��)��A'X��O�SU�$J�� #;� %��-��5�-!I� �g��5��'8�5��)}�� .�-�O��&[�-��J��& ��-��H�46C78)��_� �M)�"� M0E��}��5��"�0-&5�_��)�"��PSU�$J�� #V� �� $32��)-��-!�)Q�.�-�� D"��Q�5�-!�� $32 ��)�"$J��,0E��P!��-��"��P?b��)��SU�$J��5��#<��!�"�� "�� ~3H�-��80H#<��)��DO��&��>�-�� #.6H78)�"��8��"$#<02��02��"�� D��)��SU�$J��5��#A��.�-�9� :� ��"�� 50-&5�ANb02��)\� �<��)��1 �� 1��?�02�� !=��)H#H ��5��"�&5& #A��-"$J$"�� & "�0-&5�H3"��-�I�� -�,"�0-&5#\� �I02�� !A��?U��)��%��#.�2�%��)-"��B':��-&5�W02��-��&5� O��& #<?b��B�� "��#<�- �� "��-�;"��-��)-�� 9��<':"��H�9��<02��="��-��1�5�~3�02��"�� =��?C� �� 9& � ��5��;"��-��&5� ��"�0-�5& �5��#�^�3 ��)�� !A'8)�� )I��"$#\02�� I0H#<"��I��2��I �� 5�-!A��.��-��"��8��)��)��"��8��?U"��I��2��I �� +��"�� I�-��.�� $6� �$'X��J��$3H'8)-"��J��B��)-�D�� 8"��I��"$'80-"��eO. B��?~��)��<SU�$J��5��#<��H��&�3H��)��D ��Y�� 9��?9SU�$J�� #V� 1�-��"��;��$��$3-��\'8)�� );��<��2��; ��-��=��a�� 1)-"$J��= ��<?b"� �� !��-��~3C �� e��@3C�-�.�� \ ��J��;��h�5& & �� "��_��)�"��<��2�� -��_�-��J��& ��E�� \"��5�-��_� �H�� ;� �;�5��-��$J.� ��!\"��-�;��)-��;"��-J��5 ��5�-!<��)��=f.�-"�& � ��#I��?C��)-�� 9��.��Y�� $3d ��g��)�"��A� ?9"g ��& � �� +��"�� -��.�� M��"��02�W��J��& ��2��~3d��5J$"�� "��5�� "��5�I�5�8 �)��& ��-��802�D& "��OH�5�-!�6

��h�C�9�V� �9¡H¢ �C�£ ��'¤��)��-��&5��!��5��"�&�"��-J$"�� a3H ��e)�"� 8�� !23H��"$#M0E�D�� Y �"��#%��1��"�O��*��2��, ��*��5+-��"�� ,��"�� "�&¥� �,��)��*?b"��*��?��)��*�"�� ,��$J��

¦U§¥¨�©Wª¬«4�®�¯�¨>°2¨�® ±@²´³�¯�µ�±�²´«4© ¶·5¸-¹�º�»�º�¸.¼9·5¸_¼�¹�º>½�¾2º�¸_¿�½�À�»�Á�º>Â�º�Ã�º�Ä5½�¾-Å,º�¸.¼9¾�»�½HÁ�º�¿�¿$Æ~Ç*·5Ã�º�¸_¼�¹�È�¼9Á�½.Â-º�Á�· Ä�É�È�¸_·5¸-Â�º�Ê¾2º�¸�Â-º�¸H¼/È�Ë�º�¸�Á�ÌHÉ$· ¼�¿�º�Ä Í2½�¾Eº�»�È�¼�· ¸�Ë�È�¸�½�¾2º�¸�¿�½�À�»�Á�º*¿�º�Å�È�¸.¼�· Á�È�Ä5Ä Ì.ÊZÎ�È�¿�º�ÂAÁ�º�»�¼�· Ï�Á�È�¼�·5½�¸¾�»�½HÁ�º�¿�¿$É$È�¾-¾2º�È�»�¿C¼�½DÎEº*ÈD¾2½�¿�¿�·5Î-Ä5º8È�¸�¿�ÐXº�»/¼�½D¼�¹�º8Ñ.À-º�¿�¼�·5½�¸�½�Í�Ð8¹-È�¼/¿�¹�½�À�Ä Â�È�¸�½�¾2º�¸¿�½�À�»�Á�º[Á�º�»�¼�· Ï�Á�È�¼�· ½�¸M¾-»�½.Á�º�¿�¿XÁ�½�¸�¿�· ¿�¼`½�ÍVÈ�¼`·5¼�¿X¹�º�È�»�¼$Æ�ÒXÀ-·5¼�º[Ð8¹�È�¼`È%Á�º�»�¼�· Ï�Á�È�¼�º[·5¼�¿�º�Ä5Í¿�¹�½�À�Ä ÂWÄ ½.½�Ó\Ä ·5Ó�º%· ¿BÈM¼�º�Á�¹-¸�· Á�È�Ä�Ñ.À-º�¿�¼�· ½�¸I¼�¹-È�¼[Á�È�¸WÎ2º�Ä º�Íb¼B¼�·5Ä Ä�Ä È�¼�º�»$É¥Î�À-¼B· ¼B¿�¹�½�À-Ä5ÂÁ�º�»�¼�· ÍFÌhÈgË�· Ã�º�¸�Ã�º�»�¿�·5½�¸�½�Í9¼�¹�ºI¿�½�ÍF¼�ÐXÈ�»�ºIÈ�Ë�È�· ¸�¿�¼�ÈgË�· Ã�º�¸�Ã�º�»�¿�·5½�¸�½�Í9¼�¹�ºI¼�º�¿�¼�·5¸-Ë¾�»�½HÁ�º�¿�¿$ÉHÈ�¸-Â�Å�È$Ì<¹-È$Ã�º�È�¿�¹-½�»�¼8¼�· Å�ºD¼�½�Ä ·5Ã�º�Î�À�· Ä ¼8·5¸UÆ

Ô�Õ�ÖeÕ�×�Õ�Ø9ÙVÕ�ÚÛ4ÜCÝ9Ü-Þ µ�ßàßdµ�©�áWª Ü�â%Ü�ã µ¬ä�µ�åMµ�©�²ZæUç ÝCè ¨>ª¬é2êDën§�®�«.ä ¨�¯�±¬ì�í�¨�î.�ï4ï4²à©.ïDð�ñ�ð�±�¨�ånð «4ò ±ôó8µ�®�¨*õ�²ôµ

ð ±¬µ�±�²´¯>µ�©Eµ�ß´ñ�ð�²àð�æ ö�²à©_÷�øZù¬úeû�÷:ü~÷�ýnþ ÿ��÷~øZùeú�� *ù��~÷~ý��! !"#��$�%��'&�2ù�$�(�eø)��.ú��9ù�A÷~ø��*�ú�� +-,.�� *ù��X÷�øZù��eø0/�1�12��9ý3/��45/�� æ76�898:6 Ü

6 Ü<; µ�ßà¨�®�²Zµ Þ ¨�®�±�µ�¯�¯�«¥æIç�ª�¯�µ�ßôµ�î.ßà¨>=Dµ�®�á�óBµ�®�¨ ; ¨�®�²à³.¯aµ�±@²´«4©nóC²à± è ª¬ñ�å[î¥«4ß´²à¯¤ª¬²´å[�ßZµ�±�²à«4©�öª¬§.®�²à©�ï$¨�®<?Dª¬ê�æ76�898:@ Ü

A4Ü�B�Ü Ý[Ü~Þ ®�¨�.¨�®,µ�©�áDC ÜEB�Ü~Þ «�óU¨�© Ü ê B~ãGF ±�±�²´¨�®=°2«$å1§�²´ß´¨�®(H�°E«4åD§�²´ßà¨�®�ì%IU¨�©.¨�®�µ�±@²´©�ï è ²àï è ¨�®«4®�á.¨�®�§Vµ�®�ð�¨�®�ð�²´©>° Ü �.ù��(��JK/$ø0�<L ÷�ø0/$ú��M� ú��'NPORQ)+S�eø��.ú��eæ�69T9U Û4Û9V ì Û 69@ A�W¥Û 69X4¶4æ�YX«�õ4¨�å[î¥¨�®Û X9X9T Ü

Z Ü�B�Ü Ý[Ü�Þ ®�¨��¨�®�æ�ê Ü ëAµ�®�[\ ©,é2«4§H¨^]�æ�ê Ü I8µ�® ¯9[\ µ Ü<_ ÝCè ¨`YX¨�±ôóU«4®(a Þ ßà«�¯�a�í�¨�õ�²à¯�¨5b Üè ±�±@§VìEc9c�óCóCó�6 Ü ßà²´©�edaä «4�®�©Eµ�ß Ü ¯�«4åfc�ß´äH�²àð ð��¨�ð$c�²àð�ð �¨�¶ A c A ¶4¶9g Ü è ±�å1ß Ü&��9ý��45Q2haù�4�ø��/�, æ7iD¶ A æ-ëMµ@ñj6�89898 Ü

T Ü�B ¨�±�¨�® Ý[Ü~Þ ®�¨��¨�®=µ�©.á�ê:®�©�¨lkg²à¨�îVµ�ßà¯�a _ m ©�±�¨�ßàß´²àï$¨�©a±�YX¨�±ôóU«4®(a4¨�áhª¬«4ò ±Zó8µ�®�¨ ã ê m í�bàæ m ©÷~øZùeúeû'�)�n�o&�O%pq�(��M, ûr�2ù�$�(�eø)��.ú��>ù�I÷R/$ø0/�,, ��,G/��sp�� Fø��t�45��u��ù�1<+-45��v/��s n��"J�ù$ø�w� yxF÷Rpz�� q�aÿ$ÿ�{�|~}'��$ø)�s�(�!�G&�ORp��)��M, û'��4S, ��"^�2ù�$�(�eø0��.ú��>ù��G+�+-,.��s�($��ù$ø�1�/��"� ú� æ F á�ð Ü�Ý[Ü~� µ è ®�²´©�ï4¨�®�æHë Ü = Ü =Dµ�åz]�µ4æ3U m ª Þ YD89H�g9g9X9g9@�H Z @9g�H A9V §�§�T Û ¶�H�T9696$æ m ©�©�ð î�®��¯�a-æêX�ð ±�®�²ôµ4æ�ê[° Ý ê B ®�¨�ð ð�æ � ¨�î�®�Eµ�®�ñj6�898:T Ü

@ Ü�B�ÜaÝ[Ü-Þ ®�¨��¨�®[µ�©�áIë Ü I8µ�® ¯�²�[µ ; µ�ß´ßàð�æ~ç�ª¬±�µ�±@²´¯*á�¨�µ�á�ß´«�¯�a%á�¨�±�¨�¯�±�²à«4©,²à©=± è ¨*ß´²´©aedva4¨�®�©�¨�ßZæ ö²´©\÷�øZù¬úeû��%��,.�/�t�,.�r��ù��MJK/aø0��&e��ú��.ù�, ù�� <�l�%��/�"#OR4�ø@ù�+S�`�aÿ$ÿ��}��z��/�"#OR4�øZù�+S�r�)��eø�"�/�� ù��/�,K��ù��eø0��.ú��8ù��R��, �/�t�, �`�.ù��(��JK/$ø0��&e� ú��ù�, ù�� æ�ð ¨�® Ü é�YD°Cª�æ�ê Ü é2ßôµ�åD«4ð�[\ µ�©�áê Ü ª¬±�®�« è åD¨�²à¨�®�æ F á.ð Ü æ�©�« Ü7A 8:@ A4Ü ª¬§�®�²´©�ï4¨�®�æ7C��©�¨�6�898 Z æa§.§ Ü T96 W @ Z Ü

¶ Ü�B�Ü�Ý[Ü2Þ ®�¨�.¨�®Dµ�©�á_ª Ü�B ²à¯�aa²´©Eæ/ç�¦U©�¨BåD²àß´ßà²´«4©�U é/¦8° V µ�©�áA¯�«4�©�±@²´©�ï¥ì2ª¬±�µ�±�²à¯=µ�©Vµ�ßàñ�ð�²´ð`ò «4®¨�®�®�«4®�ð1µ�©�á�õ��ßà©.¨�®�µ�î�²àß´²´±@²´¨�ð`²à©�± è ¨8é2²´©aed�a$¨�® ©�¨�ß�ð�«4�®�¯�¨B¯�«aá.äæ ö�²à©_÷�øZù¬úeûR�R��, �/�t�, �2�.ù��(��"JK/$ø)�s&e� ú��ù�, ù�� `��%��/�"#OR4�ø@ù�+S�2�$ÿ$ÿ��}R��M��/�"#OR4�øZù�+S�2�(��M�eø��/�� ù��/�,��2ù�$�(�eø)��.ú��ù��%��,.�/�t�,.��.ù��(�MJR/$ø0��&S��ú��.ù�, ù��*�� æ�ð�¨�® Ü é�YD°/ª�æ-é Ü ë Ü�B ²à© è «;µ�©�áhë Ü I Ü =Dµ�®�î¥«4�®�æF á�ð Ü æa©�« Ü Z 898:@ Ü ª¬§�®�²´©�ï4¨�®�æ�C��©�¨�6�898:@4æ�§�§ Ü T9@ W ¶�8 Ü

g Ü�B�Ü�Ý9ÜaÞ ®�¨��¨�®Cµ�©�á�ª Ü5B ²´¯�a�²´©Eæ�ç�ª¬ñaå9îH«$ßà²´¯UêX§�§�® «�d�²àåMµ�±�²à«$©Eì�êX©[êX§�§.®�«¥µ�¯ è ±@« ; ¨�®�²´³�¯�µ�±�²à«4©²´©,± è ¨Bédµ�®�ï4¨�ö��)�.ù��/�� ù�� e�~ ��M��1� �/��.ù��(��JK/$ø0�2O%e��eø��*e�2�� !�!��haù�4�ø�"�/�, æX¦U¯�± Ü 6�898:@4æXª¬§�®�²´©�ï4¨�®�æ�é�«4©.á�«4© Ü ¦~©�ß´²´©�Äõ4¨�®�ð�²´«4© è ±�±@§VìEc9c�óCóCó Ü ð�§�®�²´©�ï4¨�®�ß´²à©�a Ü ¯�«4åfc¯�«4©�±�¨�©a±$c�î A @� A a A g9696� Z ±$@ Û Z Ü

X Ü�B�ÜHÝ9Ü�Þ ® ¨��¨�®>µ�©�ágª ÜKB ²à¯�aa²´© Ü ê:î�ð�±�®�µ�¯�± m ©a±�¨�®�§.®�¨�±¬µ�±@²´«4©\åD¨�¨�±�ð>ëD«�á�¨�ßX° è ¨�¯�a�²à©.ï=©.äµ�®± è ¨ Û 8:�Eé/¦*°AåMµ�®(a ÜSm ©A÷~øZùeú�{��)��M�¬ø�e/�� ù��/�,o�Aù$ø�w� ��$ù�+�ù�v�'4S�bù�1�/��M��y�3�¬ø�� Eú�/�� ù�ù��)$�Ge�*�M��"#�e��/��~ ��1� �xM�<�G�(�`þ ÿ��| ; ²´¨�©�©Eµ$æ¬êX�ð ±@®�²Zµ4æ Û êX§�® ²àßZæe6�898:@Ù ³�©Eµ�ß.õ4¨�®�ð�²´«4©D±�«µ�§�§¥¨�µ�®�²à© F ß´ð�¨�õ�²à¨�® F ßà¨�¯�±�®�«4©�²´¯'YX«4±�¨�ð�²à© Ý °/ª V æ F á�ð Ü�ã µ�åD¨�ð èMÞ�è µ�®�µ�á�ó8µ*µ�©�áMª¬�§.®�µ�±@²�aëDea è «4§Eµ�á è ñ¥µ�ñ Ü

Û 8 Ü�B�ÜeÝ[Ü�Þ ®�¨��¨�®`µ�©�á�ª Ü5B ²à¯�a�²à© Ü í~¨�±@¨�¯�±�²´©�ï�í�¨�µ�á�ß´«�¯�a�æ�í�«$�î�ß´¨�H � ®�¨�¨8µ�©.á�¦~± è ¨�®VêXî�.ð�¨�ðV²à©µXëD²àß´ßà²´«4©[é2²´©�¨�ðE«4ò.é�²´©a�d â ¨�®�©�¨�ß�ª¬«4�®�¯�¨ m ©,÷~øZùeú¬û:�$ÿ��M�r�'��45/�,S�)O%ORO-�- !�!��.ù��(��JK/$ø0�O%e��¬ø��*e�z�Aù$ø�w� ��$ù�+�xM��O��s"#�$ÿ�|�é�«�ñ4«4ßZµX°2«4ß´ßà¨�ï$¨ÌU®�µ�á�Eµ�±@¨8°E¨�©�±@¨�®�æ�°E«4ßà.å[î�²Zµ4æaëMí:æ?Dª¬ê�69T�H�64¶XêX§�®�²´ß�6�898:@ Ü

� �� 7¡-¢E£�¤�¢�¥�¦�¥e§�¡- ¨� �©�ª(«^¬e«^ª

99 �¡- �¨� �©�ª(«^¬�«^ª'¦�¥e§��e 5¡:¢�£�¤5¢E¥G 3®�¯�«^£�¤5¢E¥e°n±²9ª<³R«5¦�§e´�²5£�¤�µ�³R²9¬�¶eÉ«^·�¸�ª�«^«�¦�¥e§�¹�º(¯e«^ª�»�¶e¬e¼(«^¼¢�¥Pº(¯e«�½�¢E¥5¬e¾u¿`«^ª(¥e«^´l��²9¬eª�£^«u®�²5§e«5µRÀ�ÀÂÁ9Ã9Ä�·�Á9Á9ÅÆ¢�¥ÂÇ%È�É�Ê2Ë�ÌqÇ%É0Í�Î�Ï�ÐsÍ�É�Ñ�Ò�Ó�Í�ÔÕÍ�Ö× Í�Ø<Ô-ÙSÊMÈ�Ê�ÚÍ�Ö�È�Û�ÜeÎ�ÚÝ�Ö�Î�Ý�ÚÖÞÜ�Í�ß(Ê�àKÈ�É0ÝyáRÖ�â�ÚÖ�Ý�Ý�É�ÚÖ�â�ã × Ü�Üeávä å�æ�ç9è!é%Ý�È�ê�Ú*Öeâ�è2ëGì�èní�î�ï#ð�ñò È�ó�í�å�å�æ�µ9ô%§e¼$ 9õz � ~»n´�«^¾7¦�¥e§eª(²$ö7µ:÷` :³R¢�£�¤zö�¦�¥v»n´�¶o¦�§o¦9µ:¡- :øs 9»z :��´�²�²9º$µ:ù� :³R²�¥e°:¦�ª(ª$¦9µ��À�ª(¢E¥e°�«�ª<½�úz®'��û9ü�ü�ý:µ7¹�¾�±²9ª�§oµ�þ��e©�ú�û�·�Ä�ý9ÿ9·�û�ý:û9�9Ä�·�Á9

9Å9 ��e R¡-¢�£�¤5¢E¥D¦�¥e§D¡- :¨� R©�ª�«�¬�«^ª$ y��¶:²9É¢�£z»�ÀeÀeª(²$¾�¢��f¦�º)¢�²9¥��:»qö«^£�¯e¥e¢��5¬e«f¦�¥e§D¦�ö²5²9´±²9ª�õR«^ª(¢�e£5¦�º(¢�²9¥v¢E¥vº(¯e«n½'¦�ª(°9«5µ~ÀeÀG 3ü9Á�·��ÿ9ý�¢E¥PÌ:Í�Û Ïoí�è�ÇRÉ)Í�Î�Ïoí�ÖeêlË)Ö�ÊMÝ�É�Ö�È�Ê�ÚÍ�Ö�È�Û × Í�Ö�ß�Ý�É�ïÝ�Ö�Î�ÝzÍ�Ö Ë)Ö�Ê�Ý�ÛÛ.Úâ�Ý�ÖeÊ × Í�Ø<Ô-ÙSÊMÝ�É × Í�Ø2Ø�Ù5Ö�ÚÎ�È�Ê�ÚÍ�Ö È�Öeê�Ç%É0Í�Î�Ý�Ò�Ò�Ú*ÖeâláRÖ�â�Ú*ÖeÝ�Ý�É�ÚÖ�âfãMË ×'× Çí�å�å�æ�ç9èRñ�ï#í�Ü�Ý0Ô-Ê�Ý�Ø��Ý�É�èRí�å�å�æ�è �'ëuÍ�ß × Û Ù��(ï��!È�ÔeÍ�Î�È�èKé%Í�Ø�È�Ö�ÚÈ�µ5ô%§o 5þ#²:¦�¥y»nÉ±*ª(«^§�½�«^º(¢0¦9µ� 5¨� 7¡-ª(«^¼~µ7®�´�¬��·�úz¦�À:²5£5¦9µ7Å�ÿ9ÿ:Ã9

9û9 �¡- �¨� 5©�ª(«^¬�«^ª!¦�¥e§y�e S¡-¢E£�¤�¢�¥o �õK«^ª(¢��e£5¦�º(¢E²�¥�¢E¥2º(¯e«�½�¦�ª�°9«�ö�¢0¦��¶:²9´�¢E£�»nÀeÀ�ª(²�¾5¢�f¦�º(¢�²9¥oµº(² ¦�ÀeÀ3«5¦�ªf¢�¥uí�ÖeêyË)Ö�Ê�Ý�É�Ö�È�ÊMÚÍ�ÖeÈ�ÛoÜ�ó~Ø<ÔSÍ�Ò�ÚÙSØ Í�Ö��3Ý��Ý�É0È�â�ÚÖ�â��GÔ�Ô-Û.ÚÎ�È�ÊMÚÍ�ÖeÒrÍ�ß��3Í�É�Ø�È�Ûò Ý�Ê�Ó�Í�ê�Ò�è�Ì3Ý�É�Ú �GÎ�È�ÊMÚ*Í�Ö�È�Ö�êuÌ3È�Û.Úê�È�Ê�ÚÍ�Ö ã*Ë(Ü��qí�å�å�æ�ç9è'ñ! �ï#ñ!"#�!Í!��Ý�Ø��Ý�É�è'í�å�å�æ�è'Ç%È�ïÔ-Ó�Í�Ò�è × ó�Ô-É�Ù5Ò�µ

�ý: �¡�«^ª�®�«^§e«^ª$��ö5¢E¼�ºz«^ºf¦�´# �µ�%M¨<¯e«�®oõz�&�f¦�¥5¬o¦�´(' õR«^ª(¼(¢�²9¥ øf¦�¥o¦�°9«)�z«^¥�º�*'¢�º(¯ ®oõz��+:µún«^º,*�²9ª(¤v¨<¯e«^²9ª-�v½�º(§o

9Ä9 ��e n®o¯o¦�¤5¢#µKô� n®o´#¦�ª(¤9«5µK»z n÷�ª�²�£^«5µn�e nù�¯o¦�¦�¥e§/.z KõK«^¢�º(¯oµ0%�ø2²5§e¬e´0¦�ªvö�«�ª�¢�e£5¦�º(¢�²9¥�²9±¼�²9±º�*`¦�ª(«2£^²1�zÀ:²9¥e«^¥5º(¼�¢�¥�®<µ +�¢E¥PÇRÉ0Í�Î�Ï�Ë(ÖeÊ�Ý�É�Ö�È�Ê�ÚÍ�Ö�È�Û × Í�Ö$ß(Ý�É0Ý�Ö�Î�Ý�Í�Ö�ÜeÍ�ß�ÊMàKÈ�É0ÝváRÖ�â�Ú*ïÖ�Ý�Ý�É�ÚÖ�â�µ7øf¦2�jÅ�ÿ9ÿ:û9µ�ÀeÀG 7û9�9Ä�·�û9�9ü9

9Ã9 �¡- �®�²9¬�¼(²9º�¦�¥e§43! %®o²9¬e¼(²9º$µ�%M»n¶e¼�º)ª$¦�£�º�¢�¥�º(«^ª(Àeª(«^º$¦�º(¢�²9¥��-» ¬�¥e¢��«^§�´#¦�º(º(¢E£^«5�z²5§e«^´%±*²9ª¼�º�¦�º(¢�£�¦�¥o¦�´��¼�¢E¼R²9±3Àeª(²9°9ª$¦6�z¼K¶��£�²�¥e¼(º(ª(¬e£^º(¢�²9¥2²9ªn¦�ÀeÀeª(²$¾5¢�f¦�º(¢E²9¥z²9±7�e¾5À3²9¢�¥5º)¼~µ +�¢�¥sÇ%É0Í�Î�Ï8�Ê�Ó9� × ò Ü�ó$Ø!ÔSÍ�Ò�ÚÙ5Ø Í�Ö�Ê�Ó�Ý�Ç%É�ÚÖ�Î�Ú Ô-Û.Ý�Ò<Í�ß'ÇRÉ0Í�â�É0È�Ø�Ø2ÚÖ�â:�3È�Öeâ�Ù5È�â�Ý�Ò�µ39ü9Á9Á9µ~ÀeÀo �Å9û9�<;Å9Ä9Å9

9Á9 �³� oôR¥�°9É«^ª$µ<©' �®o¯e«^´�±(µo»z <®o¯e²9¬Õ¦�¥e§Õ�e �.z¦�´�É«)�fµ�%�®o¯e«^£�¤�¢�¥e°D��¼�º(«=�>3G¬eÉ«^¼ � ¼�¢E¥�°��5¼(º(«)�z·��À3«^£^¢��e£5µ�¡:ª�²9°9ª$¦6�0�2«^ª(·@? ª(¢�º(º)«^¥�®o²1�zÀe¢�É«^ª<ô%¾5º)«^¥�¼(¢�²9¥e¼-+:µ5¢E¥�Ç%É0Í�Î�ÏA8�Ê�Ó�Üeó~Ø<ÔeÍ�ïÒ�ÚÙ5Ø Í�ÖB�-ÔSÝ�É0È�ÊMÚ*Öeâ�Ü�ó~Ò�Ê�Ý�ØDCnÝ�Ò�Ú*â�Ö�È�Ö�ê�Ë(Ø<Ô-Û.Ý�Ø�Ý�ÖeÊ�È�Ê�ÚÍ�Ö ã6�RÜEC�Ë�í�å�å�å�ç~µ�¹%£^º$ �Å�ÿ9ÿ9ÿ:µÀeÀG 76;:9Ã9

9�9 :F�G!GIHKJ,L!L�M!M!MON2P!Q1R�STN2Q1UWV�XWY�Z�G![�N2Q1U)\7LWYI]!S�^`_ba!acNdF�GW\7a9µ�¦�£^£^«�¼�¼(«^§�9Ä1e�ÿ:Á!e�ÿ:�9ü9 �ù� 7�� ¸3²9¼(º(«^ª$µ�øs 5¸gf¦�¯e¥�§eª(¢�£�¯oµ�¦�¥e§y»z �»�¢E¤9«^¥oµT%M» º(¯e«^²�ª-�v²�±oº��5À3«h��¬o¦�É¢��e«^ª(¼$µ +z¢�¥�Ç%É0Í�Î�Ï� × ò Ü�ËWi%Çj��g� × Í�Ö�ß�Ý�É0Ý�Ö�Î�ÝvÍ�Ö�ÇRÉ0Í�â�É0È�Ø�Ø�Ú*Öeâk�3È�Öeâ�Ù5È�â�Ý5CnÝ�Ò�Úâ�ÖjÈ�Ö�êsË)Ø!Ô-Û Ý�Ø�Ý�Ö�ÊMÈ�ïÊ�ÚÍ�Öuã*Ç��lC�Ëeä "!"�ç~µ�øs¦-� 9ü9ü9ü9

Å�ÿ: �ù� -�e �¸�²9¼�º(«^ª$µ�¨� �ö«^ª$¦�¬�£�¯e¢0µ-¦�¥e§�»z �»n¢�¤9«^¥oµ�%M¸G´�²�*<·�¼(«^¥e¼(¢�º(¢Eö9«�º��5À:« �5¬o¦�´�¢�e«^ª(¼~µ +2¢E¥�Ç%É0Í�Î�Ï� × ò Ü�ËWi%Çj��g� × Í�Ö�ß�Ý�É0Ý�Ö�Î�ÝvÍ�Ö�ÇRÉ0Í�â�É0È�Ø�Ø�Ú*Öeâk�3È�Öeâ�Ù5È�â�Ý5CnÝ�Ò�Úâ�ÖjÈ�Ö�êsË)Ø!Ô-Û Ý�Ø�Ý�Ö�ÊMÈ�ïÊ�ÚÍ�Öuã*Ç��lC�Ëeä å�í�ç~µ�ù�¬e¥e«�Å�ÿ9ÿ:Å9µ5ÀeÀo 7<;:9Å9

Å99 ��e eø2£5®o²9¥e¥e«^´�´#µlmE¹�À3«^¥�·M¼�²9¬eª(£^«K�2«^º(¯e²5§e²9´�²9°1�l��ª(«5¦�§��r±*²9ªGÀeª�¢�z«�º(¢��z«`n-o�Ë)á%áRá�ÜeÍ�ß(ÊMàRÈ�É0Ý�µ9Ã1pýrq(µ�À�À�Ã�·��9µ�9ü9ü9ü9

Å9Å9 �øz²�£�¤�¬e¼~µ�»z �µ�¸G¢�«^É§e¢�¥e°:µl3! ¨� tsu.n«^ª(¶�¼(´�«�¶Gµ7ù�µ(m » £5¦�¼(«`¼(º(¬e§E�v²9±o²9À:«�¥�¼�²9¬eª(£^«`¼(²9±º,*`¦�ª(«§e«^ö9«^´�²9À��z«^¥5º��~º(¯e«!»�Ào¦�£�¯e«!¼�«^ª(ö9«^ªWnE 3þ#¥ ÇRÉ0Í�Î�Ý�Ý�ê�ÚÖ�â�Ò<Í�ß'Ê�Ó�Ý`í�í�Ö�ê2Ë(ÖeÊ�Ý�É�Ö�È�ÊMÚ*Í�ÖeÈ�Û × Í�Ö�ß�Ý�É�ïÝ�Ö�Î�ÝvÍ�Ö�Ü�Í�ß�ÊMàKÈ�É)ÝváRÖ�â�Ú*ÖeÝ�Ý�É�ÚÖ�â�pþ^®<��ôqÅ�ÿ9ÿ9ÿrq(µ`À�À�Å9Ã9û�·�Å9Á9Åu½�¢�z«^ª(¢�£�¤�µ3þ#ª(«^´0¦�¥e§oµ3»�®'ø¡-ª(«^¼(¼~µ7Å�ÿ9ÿ9ÿ:

Å9û9 <ô� ��e �3!¦2��z²9¥e§oµ��Ó�Ý × È�ÊMÓ�Ý�ê�É0È�ÛSÈ�Ö�êrÊ�Ó�Ýwv�È!x�È�È�É�µ-®<¦6��¶eª(¢�§e°9«��5¹�n�3o«^¢�É´��ksj»n¼(¼�²�£^¢0¦�º(«^¼$µ9ü9ü9ü9

Å�ý: <»z l3o¬�¶e¢E¥�¢# (��Ú*ÖeÙby�C�Ý��Ú*Î�Ý9CnÉ�Úz��Ý�É�Ò� <¹:n�3G«^¢E´�´�5µ��«^¶o¦�¼�º)²�À3²9´�®�»zµ5¸�«^¶o �9ü9ü9�9 Å9Ä9 (.z¦�²v®o¯e«^¥oµe³� S³%«5¦�¥s¦�¥e§s³� �?P¦�°9¥e«^ª$µ�%�ø2²5§e«^é£�¯e«^£�¤�¢�¥e°�²9¥e«K�z¢E´�É¢�²9¥2´�¢E¥�«�¼R²9±K®y£^²5§e«5µ +¢�¥DÇRÉ0Í�Î�Ï<ñ�ñ�ÊMÓ{�'Ö�ÖeÙSÈ�Ûj�!Ý�Ê�àKÍ�É�Ñ�È�Ö�ê#C�ÚÒ�ÊMÉ�Úz�Ù5Ê�Ý�ê�Üeó~Ò�ÊMÝ�Ø Ü�Ý�Î�ÙSÉ�Ú*ÊMóyÜ�ó~Ø<ÔSÍ�Ò�ÚÙSØ�µ:¸3«^¶o Å�ÿ9ÿ9ý:

Å9Ã9 �3! Rù�²9¯e¥e¼(²�¥P¦�¥�§D³� r?P¦�°9¥�«�ª~µ %M¸G¢�¥e§e¢�¥e°�¬�¼(«^ªWe�¤9«^ª(¥�«�´%À3²�¢E¥5º(«^ª`¶e¬�°9¼h*'¢�º(¯jº��À:«l¢E¥�±«^ª(·«^¥e£^«5µ +z¢E¥�Ç%É0Í�Î�ÏRñ�ð�ÊMÓjëKÜeá��!Ë-|ÕÜ�Ý�Î�Ù5É�ÚÊ�ózÜ�ó~Ø<ÔeÍ�Ò�ÚÙSØ�µ�»�¬e°: 7Å�ÿ9ÿ9ý:

}O~r�)��1��-�)�k��)�$�2��6�-��1� �

�1�1��:�!� �6�1��)�W�� `� �1�-�-�)�W�`� �!�� -�)�O�)�W��<�� 0�!� ��1�)�� -�$�T�-�-�)~��-��h�6�-�� 6��-�1¡¢ �6�-�)�h��)�-�)�)�2��1�h�1£b¤��¥r�)��¦1�)�$�-��h¦`��§��)�W�6¤��§��-��)�I� ¨g��©jª,«�¬�7®g¯�°²±A«!ª<³(´!µE¶�·w¸z¹6°@ª6¸dº�»�°@¯6¶¼E½I¹$°@¯�¾¿¼E¯6¬�»�ª<¸z°@½{Àd®w·w¼E¼WÁ�¼E½I¾(Âb«!¹6¸z»b¾¿Ã!Ä!Ä!Ä!� � �)¤ �t�6Å!Å1År�

Four Compass Points in the Verification of the

Linux Kernel

Peter T. Breuer1 and Simon Pickin2

1 School of Computing, University of Birmingham, Birmingham B15 2TT, [email protected]

2 Depto. Telematica, Universidad Carlos III, Leganes, Madrid 28911, [email protected]

Abstract. In this short paper we discuss our experience with thelightweight formal verification of properties in the Linux kernel, an opensource code base of approaching seven million lines of code in size, writ-ten in mixed C and assembler for twenty-five different hardware plat-forms. We project this experience toward possible ways of achieving thelong-term integration of at least some formal methods into that mostparadigmal of open source development processes.

Introduction

As authors of a suite of analysis tools which has been used to scan the Linuxkernel [26] source for vulnerabilities [7, 8, 9, 10, 11, 12, 27, 13], and as authorsfor many years of open source [25, 23] software projects with provenance bothwithin [5, 6, 14] the Linux kernel and without [4], we have experience of thedifficulties inherent in the treatment by formal methods of large and small, buttypically uncentralized and fast-moving, open source projects. This documentdistills our experiences with the Linux kernel in particular and presents someforward-going views.

Jumping ahead, we will contend that formal methods can find a role in theopen source software process of the Linux kernel provided they are integratedinto what may be referred to as the ‘economics’ of the development cycle in away that induces gains for all involved.

One first has to ask what fuels the economy referred to above, and whatare its inputs and outputs. Certainly, in anodyne terms, the inputs are peoplestime and effort, and the output is source code. But how are people paid for theirinput? The real answer is: in kudos, peer recognition, marketing opportunitiesfor their skills, career enhancement, a sense of involvement in a social good, inoutlets for creative skills, and so on. It is true that many kernel authors arealso nowadays supported financially by companies and other organizations, butminus the financial support they would contribute anyway.

For a formal method to find a place in this economics, we contend that (1)its output must enhance the quality of the code it is applied to in a way that isseen as worthwhile by the existing community, or it will be taken no notice of

Verification of the Linux Kernel 11

(“no market”); (2) it must provide a means to contribute by those who do havethe skills to work the method, if not the skill (or time) to write code themselves,or nobody will apply themselves to use it (“no opportunity”); (3) it must beof such a level and character that it is open to improvements and involvementfrom a wider community, hopefully containing also the target code authors, orit will wither away (“no access”); (4) the time and effort involved in using itmust be adequately recompensed by the recognition and status afforded by (1)(“no reward”).

The ‘no’s in quotes in the parentheses in the preceding paragraph representways of making sure that a formal method cannot find its way into the Linuxkernel open source development process. If those ‘no’s are removed, then thereis a place and that is the message and the conclusion of this paper.

We will start here with a short description of the analysis toolset that wehave created and used on the Linux kernel, describe the Linux kernel projectitself, give accounts of other work with similar analysis tools in the same orrelated settings, and then proceed directly to a discussion of our experiences,concluding as we have above, that four elements are required for successfuladoption of formal methods in this setting.

The toolset

We do not pretend to describe our analysis toolset in detail here. That job isperformed more than adequately by references such as [7, 8, 9, 10, 11, 12, 27, 13].For the purposes of this paper the generic description below suffices.

Our analysis toolset is written in C for speed and acceptability in the opensource environment into which it is expected to fit. It is comprised chiefly of alightweight verification technology core with the following salient features:

• symbolic descriptions of abstract program state in first order logic that arepropagated through the target C program code by customized (per-analysis)syntax-driven declarative rulesets;

• a separate system of judgments as to the goodness or badness of the analyticdescription of the abstract state derived at any given point in the programcode;

• a compiler system which converts the rulesets into C on the fly and linksthem into the runtime executables for greater speed.

• a logical decision engine based on linear mixed-integer programming, whichdecides the truth or falsity of logical implications.

I.e. the toolset comprises an analysis configuration language based on first or-der logic (with atomic predicates that comprise linear expressions in integersymbolic variables and ordering assertions between them) and a just-in-timecompiler, which allows for per-analysis customization.

As remarked in the parenthesis above, the state description logic imple-mented in the toolset is (deliberately) impoverished by comparison with someother static analysis tools. In particular:

12 P.T. Breuer and S. Pickin

• it admits no quantification and includes no temporal aspects (other thanwhat can be simulated with a specially designated symbolic time variable);

• it contains as atomic statements only ordering comparisons of linear algebraicforms in a finite number of free variables.

The (configurable) “system of judgments” in the toolset makes up for the lackof opportunity to annotate the source code in the setting of the analysis of theLinux kernel, as will be discussed in the following sections of this paper.

Judgments are monotonic in the particular sense that a a vaguer abstractprogram state description, likely the product of a less precise logic having beenconfigured into the toolset as a set of rules, will result in a worse (more negative)judgment of ant given program state. That means that more imprecision in therules for a particular analysis leads to more false alarms, because an alarm istriggered for a particular level of negative judgment and more imprecision inthe logic gives rise to more negative judgments throughout.

Conversely, more precision in the logic configured into the logical rules foran analysis run gives rise to fewer false alarms. Absolute precision in the logicof the descriptions of program state configured into the toolset for a particularanalysis (which is practically impossible) results in exactly as many alarms asthere are real errors in the code.

In practice a ratio of about 8:1 false to real alarms seems to be achievedduring analyses of the Linux kernel. That ratio is acceptable in this partic-ular context, because of the immense intrinsic difficulty of locating an errorthere even if it is known to exist (pinning down and eliminating a bug in thatenvironment can require days or weeks of hard effort).

The toolset does not depend on any external libraries which would perhapshave been perceived as too rarified in the open source context (the GNU LinearProgramming Kit, GLPK, is perhaps the most abstruse of the ones we do use).We have taken care to ensure that the toolset can be made available under theGNU General Public Licence (version 2 or later) by making sure that we havethe copyrights, and thus can avoid all licensing conflicts. Providing the toolsetas open source C ensures that it may be inspected itself by as many pairs ofeyes as care to look, and contributions can in principle come from anyone.

The target

The Linux kernel has been under development since the beginning of the 1990s.Its principal author and present chief maintainer of the development branch,Linus Torvalds, started by writing a console driver from scratch, and had madea good start on writing the operating system to support it by the time heannounced its existence on the net (usenet, i.e. the internet news protocol) andasked for help in completing the project.

That help came from all quarters. The Linux kernel project developmentkernel (version 2.6.26) currently consists of some seven million lines of mixed Cand assembler code. Some fifty to one hundred patches per day are submitted


to a phalanx of maintainers, each responsible for particular subsystems. LinusTorvalds binds in patches accepted from the maintainers into his central sourcetree, exercising editorial and managerial judgments as he thinks fit.

There are about ten thousand C source files in the current kernel source, plusabout one thousand assembler source files, plus about twelve thousand headerfiles (containing type and structure declarations, plus macros). Those servicetwenty-five major distinct hardware platform architectures, plus innumerablesubtypes. Over three thousand compilation configuration parameters controlwhich portions of the source code are exposed to the compiler. A typical Csource file is about one thousand lines in length, but becomes about thirtythousand lines in length by the time all relevant header files have been included,and macros expanded out.

The number of individual authors contributing patches each year is of theorder of several thousand, although most authors contribute only one or twoeach. There are over four hundred and fifty maintainers with responsibility formajor or minor subsystems of the kernel listed as of kernel version 2.6.24.2.

Related Work

Verification toolsets in general generally fall into two different sorts. The firstsort aims at providing proof of correctness. Such ‘heavyweight’ tools enforce astrict subset of the programming language involved and are well-suited to thedevelopment of critical software, but not well-suited to the task of improvingthe quality of legacy or open-source code. A very successful example of thiskind of tool is SPARK Ada [1]. For comparison, a reduced and verifiable subsetof C is proposed in [17].

A second sort of tool has as its aim ease of use and detection of a substantialproportion of bugs or vulnerabilities, rather than program correctness per se.Our work falls within this set. Other ‘lightweights’ include Splint [19] (derivedfrom Larch [22]), ESC/Java and Spec# [2]. Some of these tools make sacrificesin the area of completeness or soundness in order to be useful on the undeco-rated original source codes, and some require expert annotations to be addedto the source. C is a particularly difficult target for such tools, because of itspointer arithmetic and aliasing, but some notable efforts have been made in thisdirection. David Wagner and collaborators in particular have been active in thearea (see for example [28], where Linux user space and kernel space memorypointers are given different types, so that their use can be distinguished, and[29], where C strings are abstracted to a minimal and maximal length pair andoperations on them abstracted to produce linear constraints on these numbers).That research group often uses model-checking in their search techniques.

The theoretical foundations for our tools lie between those of model-checking [15], abstract interpretation [16] and contributions like Jeffrey Foster’swork with CQual [20, 21], which extends the type system of C in a customis-able manner. In particular, CQual has been used to detect “spinlock-under-spinlock”, a sub-case of one of the analyses routinely performed by our tools.


The SLAM project [3] originating at Microsoft also analyses C programs using amixture of model-checking, abstract interpretation and deduction in a way thatis related to our approach (except that we do not use model-checking). Thattechnology is an order or more of magnitude slower than ours, but also worksby creating an abstraction of the program code, and also generates intermediatestate descriptions mechanically.

The Coverity checker [18] has over the lifetime of our own project also cometo be used in the way we had envisaged for our tools. Coverity is a commercialtool based on an user-extensible version (a metacompiler) of the GNU C com-piler, gcc. Coverity itself is proprietary, and its innards are not accessible to ourreview, but we guess that the staff of the company can hand-code in to the com-piler framework any finite state machine-based computation for the purposesof a custom analysis that they have in mind. It is a less abstract approach thanours and far less so than the others described above.

Discussion

In this section we will set out a discussion of four major Linux kernel projectcharacteristics that we believe have a major bearing on success or failure of theincorporation of formal methods into open source projects, as given focus bythe four points named in the introductory section of this paper, namely: ‘nomarket’, ‘no access’, ‘no opportunity’ and ‘no recompense’. We have designatedthe characteristics, aritrarily, “North’, “South’, “East’ and “West’. The last ofthese treats of technical issues for tools, whereas the others are pure processengineering features.

Compass North: Staying relevant; today’s news, tomorrow’s history

The most influential intrinsic and generic characteristic of an open source soft-ware project from the point of view of our verification experience in the Linuxkernel has been the rapid turnover of the codebase, and its perpetuity into the

far future.There is and will be no point at which the code can ever be said to be finished

in a living open source project. The project renews – and occasionally reinventsitself – continuously in direct correlation with its vitality. Therefore verificationmust intrinsically be of only a transitory validity. Tomorrow the code base willhave changed and the verification conducted today may be invalid as a result.

That means that a complete verification analysis must be run every day, orelse techniques must be developed that can re-analyse only those parts of thecode that have changed since yesterday, fitting the increment into yesterday’sresults. If the analysis run cannot be completed on time, then the results areintrinsically somewhat irrelevant, and therefore devalued. With decreased value,the results of analysis find a diminished market for themselves in the contextof the project (see “no market” in the introductory section).


There is some hope for treatments of the incremental kind (see for exampleUNITY and formal methods based on it [24]), but at present we do not doincremental analysis in our own analysis suite. We have opted instead for com-plete configurable lightweight verifications from scratch that can be performedrapidly and repeated frequently. Our present tools are able to deal with themore than six million lines of C code in the Linux kernel (ca. version 2.6.22)within 24h (the measured rate on a single 1.8GHz Athlon with 512MB RAMrunning in 32 bit mode beats this comfortably). The approach is conceptuallysimpler but computationally more expensive and inefficient. We do not expectto be limited by computer horsepower in the future, particularly if infrastruc-tural support improves for the remote and distributed verification of ongoingprojects, as we expect to be the case.

Deliberately simple or not, our analysis suite has detected problems whichhave lain undetected in the Linux kernel code for years at a time in plain view ofall [7] (in that study we attributed problems in the sound drivers in particularto the fact that nobody may have reviewed the code apart from the originalmaintainer, who wrote it, and missed the problem; the contributions in questionwere so massive, consisting of the sound system as a whole, that nobody elseapparently had the stamina or desire to review all of it, and certainly veryfew people would have felt themselves competent to nay-say that author andmaintainer).

Without the widespread adoption of dedicated (distributed or not) per-project verification programs, however, it is difficult to conceive of more thaninfrequent verification of even the most prominent open source projects. As aconsequence, only particular releases of a project may ever be verified (by aparticular release of an analysis suite), and the question arises as to what valueare the results of verification if they are always out of date?

A partial answer is that even somewhat out-of-date verification results un-doubtedly often alert code authors to problems that they would otherwise havebeen unaware of, and therefore contributes to software quality. In our originalverification conducted on the Linux kernel [7] we found three deadlock-causingbugs. One we notified the authors of, and got immediate acknowledgement backfor, together with an issued correction dealing with the problem. One we heldback reporting, and found that it was found and fixed independently six monthslater. One had already been fixed in a later release by the time we found it.So even though we were not looking at a daily snapshot, only one third of ourwarnings were out of date.

Also, at the very least, verification efforts serve to enable estimates of thenumber of bugs according to some objective criterion, and therefore of thequality of the open source development process as a whole. It may be significantthat the bug rate is one per two million lines of code in absolute terms, but itis even more significant that we could objectively estimate the half-life of a bugin that particular open-source development process this way.

One particular feature of our toolset keeps it relevant where other toolssometimes fail: the output is directly readable by a Linux kernel source author


and does not need further interpretation. The line and nature of a proposed faultis reported. That is not the case where tools have translated the target (C) codeinto an internal language, and analysed that. Then the error reports are relatedto the internal representation and may need considerable interpretation to anordinary C code author.

However, even with tools such as ours which report source code errors, it issafer to filter the outputs first through someone who understands the configuredanalysis logic (and something of the target source code) in order to weed out agood proportion of the false alarms before submission to Linux kernel authors.Thus there is an opportunity for people with the right skills to contribute (see‘no opportunity’ in the introductory section of this paper). Those skills arenot the same as those of a kernel author, and so the existence of this kind oftool undoubtedly creates new opportunities for other skills to be brought intoa communty work.

But ‘what’s in it for the verifiers’ (see ‘no recompense’ in the introductorysection of this paper)? Why should someone put in the huge effort of a verifica-tion run on a source code which changes every day? The turnover devalues theeffort. There is kudos to be gained from identifying errors, but many other er-rors are identified every day without fanfare. The only possible answer must bethat it must become so much easier (and faster) to run the verifier process thatthe effort involved is reduced until the satisfaction gained becomes relativelyhigh compared to it. Then it may also be the case that authors will contributeto the verification suite itself (see ‘no access’ in the introductiory section of thispaper).

We will go on to consider this point more deeply in the next section.

Compass South: The code is not ours, so why bother

Open source code usually has a principal maintainer or maintainers who hasor have the final say on additions to or changes in the code base. But in ourexperiments on the Linux kernel we have not been in that position (althoughone of the writers of this article does figure among the authors in the Linuxkernel). That has the implication that

(a)our formal analysis has only been able to make an impact via persuasion, andnot any other imperative;

(b)we are not able to mark up the code (it would change too fast in any case tomerit the effort);

(c)we are not able to impose any particular structure or other form of codingstandards on the code;

(d)we are not able to put our names into the source code.

As regards imposing software development practices, not even the principalmaintainer or maintainers hold absolute sway over the largely amorphous devel-opment process. In particular, no mandatory process exists in the Linux kernelto incorporate or take note of the results of formal analyses for verification. In


general, the only imperative on an open source project is that it should ‘surviveand prosper’, which means that it should continue to engage contributers toand users of the software in a loosely knit community. As a corollary, no con-tibuter can be forced to submit his/her contibution to formal analysis beforesubmission, and no central maintainer can be made to apply such an analysisbetween acceptance and release. On the other hand there are some semi-formalprocesses that have made it into the Linux kernel project at different levels.

For example, the generally accepted Linux kernel syntactic coding and layoutrules have been formalized into a perl program which is run over code andpatches before incorporation firstly by some maintainers who have acceptedit into their personal engineering process, and secondly by the party whichdeveloped the checker, and thirdly by independent individuals who feel thatthey thereby contribute by doing grunt-work that frees code authors of someburdens and adds quality to the product. In the latter two cases the results fromthe checker are reported in the general Linux kernel mailing list in the form ofa patch to correct the issue identified, which is then accepted or rejected amongcriticisms that result in modifications of or additions to the checker programitself. That works in terms of refuting the ‘no access’ problem set out in theintroductory section of this paper.

The Coverity checker [18] is also being run over the Linux kernel codebaseperiodically by its creators, perhaps partly as an advertising opportunity. As weprecised in the ‘Related Work’ section of this paper, Coverity is a commercialtool based on an extensible version of the open source standard C compiler, gcc.Its operators add specialist domain-based knowledge to the “compiler” in orderto allow it to detect coding problems which have their origins in higher levelconstructs and deeper semantics than lines of code. A typical piece of domainknowledge might be, for example, that the standard C library call “close” hasthe effect of closing a file handle, or that the C library call “malloc” providesa pointer to a chunk of memory on the heap. Reference to the file handle afterclose and before “open” or “reopen” etc. would be illegal (and offers an attackvector against the software).

Coverity itself is proprietary, and its innards are not accessible to reviewand for that reason we have to guess at how it works in detail, which maybe unacceptable as part of an open source certifacition process, and certainyspeaks to the ‘no access’ point of the introductory section in a negative way.However, the model of interaction that its creators are following is otherwise aviable process in many respects for a formal method in the context of the Linuxkernel. They post details of problems they have detected in the main Linuxpublic forum and notice is taken and action is taken if the report is judged tobe valid. Like our tools, Coverity over-reports, giving false alarms. Many falsealarms are filtered out by the operators but some survive to publication simplybecause the operators cannot be as expert as the Linux authors themselves.

One common element between all the checkers and ourselves, however, isthat even when we get the kudos of an error detection, report it to the Linuxkernel authors, and have it corrected, then we still do not get our names into


the kernel source. Indeed, the object that we worked on, the bug, is excised.And when it is excised, it is excised by others. That is quite a negative resultin terms of the ‘no recompense’ point raised in the introductory section of thispaper. Searchers through the historical database might find out who found thebug that is no longer there, but nobody else will know. The eventual anonymityof the contribution serves as a damper on contributing in this way.

Compass East: No map, here be dragons

Of almost equal standing to the characterictic rapid turnover in the Linux kernelsource and indeed somewhat related to it is the characteristic that: there is at

most sketchy documentation that may serve as even an informal specification

of what the code is supposed to do, either in whole or in part.As a consequence, there is at least a question over what formal verification

may be expected to achieve, because we do not know either in detail (i) whata particular function is supposed to do (although that is the lesser problem,because in practice we can guess with good accuracy even when the descriptionis lacking or unclear), or (ii) how it is supposed to be used. The latter is thelarger problem. How can we say when a function or other piece of code is beingused incorrectly? We have no specification for the context it is used in. Withoutthe specification, there is ‘no opportunity’ (as per the points discussed in theintroductory section) for formal methods people to apply their skills.

What we have achieved in past experiments with our tools have been verifica-tions that certain clearly universally undesirable conditions of state do not ariseduring execution. We may term these conditions of ‘semantic well-formedness’,rather than speaking of (semantic) validity and validation. For example, wehave been able to say that ‘sleep under spinlock’ [7] does not occur in largeswathes of the millions of lines of the Linux code, and have identified a rela-tively small number of points where our analysis suite says it may occur (and oninvestigation, a fraction of those points turn out to be not merely feasible, butactual instances). ‘Sleep under spinlock’ may give rise to deadlock on a runningmulti-processor machine.

It has been up to ourselves to identify and formally express the condition in-volved, however – one will not find it documented that a process thread shouldnot be potentially subject to being scheduled out of the processor while a spin-lock (comprising a busy wait – spin – for the lock to be released) is held bythe thread (that is what ‘sleep under spinlock’ is an abbreviation for), althoughexperts will certainly know it as a generic and unwritten rule of coding for amulti-processor platform at kernel level.

There are other conditions that may be equally problematic, but which wedo not know about for lack of documentation. Thus each verification, apartfrom being potentially merely ‘valid for a day’, as commented above, can onlycertify an absence of a small number of the problems that undoubtedly exist inthe code. We can only say that problems we

(a) know of,


(b) know how to express,(c) know how to search for with our tools

are absent, nothing more.We can attack deficiencies in (b) and (c) via the ever-increasing sophis-

tication of our tools (generally speaking, we can presently detect any logicalcondition that may potentially arise along some code path within a given func-tion, with the results being approximate but consistently erring on the alarmistside), but (a) remains the fundamental problem. We simply do not know enoughof how the code is intended to work by design. It requires great expertise in thecode base itself to be able to abstract the design from the visible code, and wecannot be experts in everything we need to be expert in.

Examples: Two uncharted seas and one lagoon As an example of thekind of undocumented or unknown system properties that an analysis needs to‘know about’, within the last couple of years the default scheduling strategyin the Linux kernel has changed from the voluntary ceding of control – by thecurrent thread in the processor explicitly calling the schedule function or anyfunction that may do i/o – to a preemptive model in which a thread may beejected involuntarily from a processor at any point where it does not explicitlyhold a busy lock (“spinlock”) and is not in an interrupt context. The changemakes code vulnerable to errors arising out of misprogramming for concurrencyeven on a single processor platform. And then there are more subtle changesas to which functions or which kind of functionalities (for example, memoryallocations, user space interactions, filesystem interactions) can be used in whichcircumstances (in a kernel memory context? In a userspace memory context?In an interrupt-handling context? Under a lock? Not under a lock?), in whichreleases of the code and in which architectures.

As an example of a situation which we (a) know about in a general waybut (b) are unsure of how to express precisely and formally, in the Linux ker-nel (2.6.24.2) mm.h file, one finds defined the two functions “get page” and“put page”, which by inspection respectively increment and decrement the ref-erence count on a (memory) page C struct, an object which serves as wrapperfor a 4096B aligned chunk of RAM. The names of these functions indicate thattheir use is to be balanced per page over the lifetime of the page, with equalnumbers of get page and put page being applied. If an access to the page ismade when the cumulative count of put page calls may equal or exceed the cu-mulative count of get page calls, then we believe that something will be wrongwith the code. The reason is that the page might be reaped by a garbage col-lector form the moment its reference count goes to zero, and then the ‘access’would be to an object that no longer exists.

But there is no indication in kernel documentation of when or if these twopresumably complementary functions are supposed to be used by a kernel driverwriter and a search through the functions which allocate pages in that area ofthe kernel shows that many increment the page count themselves (presumablyso that the page is in no danger of being reaped in the momentary interval


between delivery to the caller and the caller incrementing the page referencecount via get page).

Moreover, other core kernel functions use one but not the other of theput page/get page pair, thus unbalancing them. A typical function that allo-cates a page is “alloc page”, which increments the reference count via get pageon a page that it returns. It may then be up to the driver writer to decrementthe page count via put page after the last use; or the decrement may perhapsotherwise be effected via a call to a different cleanup function elsewhere in thekernel. A typical function that deallocates a page is “ free page”, and it doesnot appear to decrement the reference count even though by name it pairs withalloc page, which does increment it. Thus perhaps free page is meant to be aninternal memory management function, not used by driver writers, even thoughalloc page is undoubtedly common currency. We simply do not know what theintended mode of use is of these and related functions. Worse, the designedmode of use may change from one day to the next without our getting to know.

In this particular case, then, although we know (a) at least vaguely whatthe design is and what may or may not be a problem with respect to it, ourknowledge (b) lacks the precision required to express a relevant statement informal terms. Moreover, it is even in principle hard to (c) express any statementabout this to our toolset, because the lifetime of a page object is not restrictedto any particular compilation unit.

What would improve the situation would be the existence of some fora inwhich we could ask the authors (the Linux kernel authors in this case) whatthe design really is, or what might be a useful condition of state to look for inverification. Some such fora are partially available (IRC and email lists beingthe favoured channels) but are more focussed on coders than formal methodspeople seeking the big picture. The Linux kernel mailing list (LKML) has aposting rate of several hundred a day, and it is difficult to garner attentionthere. The kernel authors have limited time and resources to spend on LKMLas it is, and discussions there tend to revolve around concrete bug reports,patches, and criticisms of patches. A kernel author is unlikely to respond to anabstract question.

An example of a situation where we have (a) known exactly of a problem,(b) known how to express it formally, and (c) been able to program it for ourtoolset is the ‘sleep under spinlock’ problem in Linux. There the classification offunctions as sleepy or non-sleepy is calculated easily from the call graph of thewhole Linux kernel. The difficulty is in determining if a function is itself designedto be called under spinlock or not, because that determines if a call to a sleepyfunction within its code should be deemed dangerous or not. If the function isnot designed to be called under lock, then a call to a sleepy function within anon-spinlocked region inside it is not dangerous. If the function is designed tobe called under lock, then a call to a sleepy function within a non-spinlockedregion inside it is dangerous and should trigger an alert. Alternatively, one mayinfer from the presence of a sleepy call within the function that the function isnot meant to be called under spinlock – thus blame for the error is not always


clearly assignable. Moreover, if a function starts by releasing a spinlock, thenone may infer that it is intended to be called under spinlock, but a sleepy callwithin its body is not dangerous. The rules are complex, but capable of formalexpression, and, indeed, expression within the configuration language of ourtoolset. A reservoir of C-literate formal methods people would overcome the‘no opportunity’ barrier highlighted in the introductory section of this paper.

Compass West: Technical obstacles for tools

Apart from the well known intrinsic difficulties in approaching the verificationof C code (single or even double indirections via pointers in the code can fatallyblind a verifier to what object is being altered or referenced by an assignment,for example), there are two features of current Linux kernel codes that haveproved difficult to deal with in practice:

(a)the increasing use of object-orientation -style late binding in the C code,leading to the proliferation of function calls where the function part is notmanifest but is instead a dereference of a writable function field embeddedin a C struct passed as a parameter, so we cannot easily tell what functionis being applied in the call;

(b)the use of persistent objects whose lifetime extends beyond any single com-pilation unit, making an analysis that is restricted to a compilation unit(function) at a time incomplete.

These difficulties speak directly to the ‘no market’ point raised in the introduc-tory section of this paper. If we cannot analyse the code, then the results of theanalysis are devalued.

An excellent example of (a) is given by the block device operations in theLinux kernel. A C struct pointer is passed to the generic block read/write func-tions which then exercise method fields in the struct which have been writtenwith pointers to functions specific to the device in question at kernel or driverinitialization time.

However, this (late binding) is not that grave a problem in practice, sinceit generally is the case that all the functions that might ever occupy a givenmethod field all share a certain abstract description that is good enough for thepurposes of the analysis. For example, when searching for ‘sleep under spinlock’,we suppose that all function calls other than “lock”, “unlock” or “trylock” callsare balanced with respect to their effect on any spinlock at all, and we classifyeach function either as ‘sleepy’ (directly or indirectly calls the scheduler) or‘non-sleepy’. If the classification scheme is incorrect for a function it will bediscovered when the code of that function is analysed (this happens – fromtime to time new core function calls are introduced into the Linux kernel codewhich have an unbalanced effect on spinlocks or other kinds of lock).

However, we do not at present have a general mechanism for constructingsuch classifications automatically, though we do have a mechanism for assigningthem. We can specify classes of function names and assign a functional type to


the class which is taken by any instance. For example, we specify the class SPIN-LOCK of which ‘spinlock’ and ‘writelock’ and ‘readlock’ and ‘spinlock irq save’are specified as instances, and assign the functional type

p 7→ p[x− 1/x]

to these instances, where x is the count of the current number of spinlocks taken(any spinlock) along the process trace, and p is the description of state beforethe function application. The result of the function application is a transformeddescription of state in which x has effectively been incremented by one (occur-rences of x in the description having been replaced by x−1, so that for examplethe description x = 0 is transformed to x− 1 = 0, or x = 1).

Note that we cannot well distinguish to which spinlock (object) a spinlock(function) has been applied. It generally is the case that a spinlock object willbe defined as a global, one per subsystem, and references to it will be viapointers that have been received as fields in structs which are arguments to thesurrounding function call. That effectively obscures the precise identity of thespinlock during analysis. It may be that a more elaborate typing system coulddistinguish among many different spinlocks, but it would still be inadequate todeal with the case where each lock is unique to one object (for example, oneper memory page), and when there are potentially thousands of millions of suchobjects in the system, being created and destroyed continuously.

The same characteristic of C forces us in practice to assume that all thepotential occupants of a given method field in a C struct have the same abstractdescription for the purposes of a particular analysis.

What we will need to do in future is derive a type for all functions withrespect to a particular analysis instead of specifying one. There are severalthousand functions in the Linux kernel and we cannot keep up to date with thedesign and implementaton changes in them.

We cannot hope to derive an abstract type like p 7→ p[x−1/x] for a function(the type we assign to functions of class SPINLOCK) but we can construct thevector pi of actual descriptions of state at the ith point of call of function f

in the code base, and compute through the function to obtain the vector p

′

iof

descriptions of state after the function has acted. The pi and p

′

iare concrete

descriptions such as x ≤ 1 ∧ y ≤ 2x + 1. Thus we can derive a vector

pi 7→ p

′

i

to serve as the concrete type of the function f , instantiating some unknownabstract type

p 7→ p

′

(p′ is some unknown form). The ith component of the vector corresponds tothe ith call site of the function in the actual code.

In the case of the type p 7→ p[x − 1/x] for functions of class SPINLOCK,the ith call site might be at a point where the abstract state description isx ≤ 1. The computed abstract state description after the function application


at that site will be x ≤ 2. We cannot discover the general type p 7→ p[x− 1/x]of the function automatically from that evidence. Another valid possibility onthe basis of this datum is p 7→ p ∨ x ≤ 2, for example.

In principle even the vector pi requires a fixpoint calculation over the wholekernel code to determine it, but real kernel code has the useful property thatthere are (or should be!) no unbounded recursions or loops in it, so fixpointcalculation is not absolutely required. In explanation, the kernel has at most8KB of call stack space (some 250 calls in practice on an Intel 386 familyplatform, about 80 calls on a Sun sparc platform, the difference being due todiffering stack frame requirements) available to it. Thus the call tree for thewhole Linux kernel is deliberately of strictly bounded depth. We could expandthe code out completely by inlining all function calls to a maximum depth of80 or 250 calls. If there are still any remaining function calls then, they willnever be executed in reality. We do have the facility to inline function calls inthe present generation of analysis tools, but it is little used as inlining merelyhas the effect of reducing the number of false alarms generated by analysis, andit has not been a significant enough effect to warrant doing the expansion inpast experiments.

Conclusion

In virtue of the foregoing ‘map’ and accompanying discussion we aver the fol-lowing conclusions. In the first place, it is clear that rapidly evolving open sourceC projects present a special configuration of challenges to verification. We havemet these challenges via an approach that emphasizes high-speed lightweighttools which do not require source code annotation. That choice reflects our be-lief that precision (in the sense of the number of false alarms) is not the mostimportant requirement of verification in such a context, rather complete, fre-quent and timely coverage of the codebase is. If that is achieved then we believethat a formal analysis process can introduce itself into an open source devel-opment process by providing feedback to the code authors. We contend thatpublicly uncovering problems that have manifestly gone undetected by humaneyes will also tend to incentivise interest in, and contributions to, the formalanalysis suite, provided the analysis suite is itself open source in nature and inspirit. We believe that a sustained positive feedback loop of this kind is neces-sary for the successful introduction of formal methods in this kind of context. Inparticular, we believe that that positive loop must consist of (1) a marketableproduct from the analysis, and an existing market for it, such as a list of lineswhere stated erros lie, (2) an opportunity for new contributers, such as formalmethods experts, to apply their skills, perhaps by composing the correct logicalrules that power the analyses, (3) access to the tools my both C authors andothers in order to improve them, and (4) adequate recompense from the inputof effort, such as recording bug discoveries and the names of the verifiers whodiscovered them forever in the project source output.


References

1. J. Barnes. “High Integrity Software: The SPARK Approach to Safety and Secu-rity”, Addison Wesley, 2003, ISBN 0-321-13616-0.

2. M. Barnett, K. Rustan, M. Leino, W. Schulte, “The Spec# programming system:An overview”, CASSIS 2004, LNCS no. 3362, Springer, 2004.

3. T. Ball and S. K. Rajamani, “The SLAM project: Debugging system software viastatic analysis,” in Proc. POPL ’02: Proceedings of the ACM SIGPLAN-SIGACTConference on Principles of Programming Languages, 2002.

4. P.T. Breuer and J.P. Bowen. A PREttier Compiler-Compiler: Generating higherorder parsers in C. Software — Practice & Experience, 25(11):1263–1297, Novem-ber 1995.

5. P.T. Breuer, A. Marın Lopez, A. Garcıa. ‘The Network Block Device’.http://www2.linuxjournal.com/lj-issues/issue73/3778.html.The Linux Journal, #73, May 2000.

6. Peter T. Breuer and Arne Wiebalck ‘Intelligent Networked Software RAID’,In Proc. IASTED Intl. Conference on Parallel and Distributed Computing andNetworks (PDCN 2005), 23rd IASTED Intl. Multi-Conference on Applied In-formatics, Eds. T. Fahringer, M.H. Hamza, (ISBN 0-88986-468-3) pp 517-522,Innsbruck, Austria, ACTA Press, February 2005.

7. P. T. Breuer and M. Garcia Valls, “Static deadlock detection in the linux kernel,”in Proc. Reliable Software Technologies – Ada-Europe 2004, 9th Ada-Europe In-ternational Conference on Reliable Software Technologies, ser. LNCS, A. Llamosıand A. Strohmeier, Eds., no. 3063. Springer, June 2004, pp. 52–64.

8. P. T. Breuer and S. Pickin, “One million (LOC) and counting: Static analysisfor errors and vulnerabilities in the Linux kernel source code,” in Proc. ReliableSoftware Technologies – Ada-Europe 2006, 11th Ada-Europe International Con-ference on Reliable Software Technologies, ser. LNCS, L. M. Pinho and M. G.Harbour, Eds., no. 4006. Springer, June 2006, pp. 56–70.

9. P. T. Breuer and S. Pickin, “Symbolic Approximation: An Approach to Verifica-tion in the Large” Innovations in Systems and Software Engineering – A NASAJournal, Oct. 2006, Springer, London. Online version http://www.springerlink.com/content/b36u3k3822u4t614.

10. P. T. Breuer and S. Pickin. Abstract Interpretation meets Model Checking nearthe 106 LOC mark. In Proc 5th International Workshop on Automated Verifi-cation of Infinite-State Systems (AVIS’06) Vienna, Austria, 1 April, 2006 (finalversion to appear in Elsevier Electronic Notes in TCS), Eds. Ramesh Bharadwaand Supratik Mukhopadhyay.

11. P. T. Breuer and S. Pickin. Detecting Deadlock, Double-Free and Other Abusesin a Million Lines of Linux Kernel Source In Proc. 30th Annual IEEE/NASASoftware Engineering Workshop (SEW-30) Loyola College Graduate Center,Columbia, MD, USA 25-27 April 2006.

12. P. T. Breuer and S. Pickin. Checking for Deadlock, Double-Free and OtherAbuses in the Linux Kernel Source Code, pp 765-772 in Part IV Proc. Workshopon Computational Science in Software Engineering (CSSE’06), Reading, UK,28-31 May 2006, Eds. V.. Alexandrov, G. Dick van Albada, P. M. A. Sloot,J. Dongarra, Springer LNCS 3994, Oxford, ISBN 3-540-34385-7.

13. P. T. Breuer and S. Pickin. Verification in the Large via Symbolic Approxi-mation, in 2nd International Symposium on Leveraging Applications of Formal


Methods, Verification and Validation (ISOLA 2006), 15-19 November, 2006, Pa-phos, Cyprus,

14. P. T Breuer and M. Valls. Raiding the Noosphere, Software — Practice andExperience, 36(4):365–395, April 2006. Wiley Interscience.

15. E. Clarke, E. Emerson and A. Sistla, “Automatic Verification of FInite-StateConcurrent Systems using Temporal Logic Specifications,” ACM Trans. on Pro-gramming Languages and Systems, 8(2):244-253, 1986.

16. P. Cousot and R. Cousot, “Abstract interpretation: A unified lattice model forstatic analysis of programs by construction or approximation of fixpoints,” inProc. 4th ACM Symposium on the Principles of Programming Languages, 1977,pp. 238–252.

17. D. Crocker and J. Carlton, “Verification of C Programs Using Automated Rea-soning”, In Proc. 5th IEEE International Symposium on Software Engineeringand Formal Methods (SEFM 2007), London, UK, Sept. 2007.

18. D. Engler, B. Chelf, A. Chou and S. Hallem, “Checking System Rules UsingSystem-Specific, Programmer-Written Compiler Extensions”, in Proc. 4th Sym-posium on Operating System Design and Implementation (OSDI 2000), Oct. 2000,pp. 1–16.

19. D. Evans and D. Larochelle, “Improving Security using Extensible LightweightStatic Analysis”, IEEE Software, Jan/Feb 2002.

20. J. S. Foster, M. Fahndrich, and A. Aiken, “A theory of type qualifiers,” in Proc.ACM SIGPLAN Conference on Programming Language Design and Implemen-tation (PLDI’99), May 1999.

21. J. S. Foster, T. Terauchi, and A. Aiken, “Flow-sensitive type qualifiers,” in Proc.ACM SIGPLAN Conference on Programming Language Design and Implemen-tation (PLDI’02), June 2002, pp. 1–12.

22. J.V. Guttag and J.J. Horning, “Introduction to LCL, A Larch/C In-terface Language” http://ftp.digital.com/pub/Compaq/SRC/research-reports/abstracts/src-rr-074.html.

23. S. McConnell, ‘Open-source methodology: ready for prime time’? IEEE Software,16(4), pp 6-8, 1999.

24. Prasetya, I.S.W.B., Vos, T.E.J., Azurat, A. & Swierstra, S.D. A UNITY-basedFramework towards Component Based Systems. UU-CS (Ext. rep. 2003-043).Utrecht: Utrecht University: Information and Computing Sciences.

25. E.S. Raymond, The Cathedral and the Bazaar, Cambridge: O’Reilly & Associates,1999.

26. A. Rubini. Linux Device Drivers. O’Reilly, Sebastopol CA, Feb. 1998.27. S. Pickin and P. T. Breuer. Symbolic Approximation: A Technique and a Tool for

Verification in the Large, pp. 97-104 in Vol. 2, Proc. 2nd International Confer-ence on Intelligent Computer Communication and Processing Engineering (ICCP2006), 1-2 September, 2006, TU of Cluj-Napoca, Romania, Ed. Ioan Alfred Letia,U. T. Pres, Cluj-Napoca, 2006.

28. R. Johnson and D. Wagner, “Finding user/kernel pointer bugs with type infer-ence,” in Proc. 13th USENIX Security Symposium, Aug. 2004.

29. D. Wagner, J. S. Foster, E. A. Brewer, and A. Aiken, “A first step towardsautomated detection of buffer overrun vulnerabilities,” in Proc. Network andDistributed System Security (NDSS) Symposium 2000, Feb. 2000.

Incorporating Formal Methods in the Open

Source Software Development Process

Antonio Cerone1 and Siraj A. Shaikh2

1 International Institute for Software Technology,United Nations University, Macau SAR China

[email protected] Department of Informatics and Sensors,

Cranfield University, Shrivenham, United [email protected]

1 Introduction

Open source software development has proved to be successful over the yearsand has delivered some high-quality system and application software. This hasincluded some popular operating systems, network services and high-end appli-cations. While such software has proved to be popular amongst users due toits reliability and efficiency, it still falls short of requirements for security andsafety-critical systems. The deployment of such systems in many domains hasto assure integrity and dependability, along with any domain-specific securityand safety properties.

Systems designed for privacy and access control, real-time scheduling andindustrial process control in industries such as public transport, automobile,avionics, health and defence undergo thorough modelling and design where eachand every functional and operational property receives rigorous treatment. Astandard approach to reduce the risks in deploying such critical systems is toestablish an independent certification process. Nowadays, this is more and moreoften enforced by laws, on the basis of international standards which define thequality of software in terms of the level of technical rigour used in the design,development, verification, validation and documentation processes as well asthe human processes involving project management, training and expertise ofproject teams, and the users’ community [27]. However, today we lack standardsand methods to assess the quality of open source software. In fact, the lack ofcentral management in open source software projects [25, 26] makes it difficultto define a standard that could suggest indicators of the technical rigour usedby a distributed community of volunteers and identify the human processesinvolved in the project.

A possible way to overcome the lack of a standard that could be easilyapplied to the certification of an open source software project is to incorporatewithin the open source development process rigorous design and verificationmethodologies whose successful use could itself guarantee the quality of thesoftware produced. A contribution towards such a kind of quality assurancecould be offered by the use of formal methods. The most recent standards

27 Antonio Cerone and Siraj A. Shaikh

actually require the use of formal methods for the design and verification ofcritical components, while for all non-critical components rigorous but informalmethods are acceptable.

Increasingly, industry leaders are looking to the open source community tosupply critical software components. Linux and BSD distributions, Apache andMySQL serve to be shining examples and are a testimony to the success andresilience of open source developers’ efforts. A recent report commissioned bythe United States Department of Homeland Security into open source software[22] finds that defect density has fallen by 16% over the last two years to theextent that such software on average contains one defect for every 4000 lines ofcode. The reputation that such products have built up over the years gives theindustry leaders confidence that the open source community could deliver muchmore. Spiralling costs of development, innovative developmental approaches,user testing and feedback, and project durability and sustainability are othermotivating factors for the industry leaders to look to the open source communityfor this purpose.

Given this context the nature of such open source systems designed for crit-ical use is undoubtedly to benefit from formal modelling and analysis methods[28]. This will allow more rigorous and automated support in the developmentprocess to assure safety and dependability attributes amongst others. Require-ments engineering, software design and development, revision and maintenanceand, documentation are all to benefit from the use of formal methods. Suit-ability of some such methods is already demonstrated for open source softwaredevelopment [24].

We propose an open ’pilot’ project to facilitate such an effort. The project isopen to volunteers who wish to come together as a team and embark upon a reallife development of a suitable system or application tool. The choice of software,formal methodology and development strategy are left to the team to decide.Ideally, the proposed effort will be monitored for its progress and effective use offormal modelling and analysis during the development cycle. The paper presentsthe way ahead, including motivations and details for setting up such an effort.

2 Proposal

The most difficult task in incorporating formal methods within the open sourcesoftware development process is to preserve the intrinsic freedom that charac-terises contributions by the volunteers who join the project. In fact, it wouldnot be acceptable to explicitly enforce the use of a specific formal modellingframework to be adopted by all project participants.

In order to support open participation and, consequently, bottom-up organi-sation and parallel development, the project must introduce and present formalmethods only as a possible but not mandatory option available to the contrib-utors. This approach may require an additional effort by the leader team inintegrating those contributions which do not make any use of formal methods.

Formal Methods in the OSS Development 28

However, it is also expectable that the challenge proposed by such an effortwould attract new potential project actors who are keen to reverse engineercode, produced by other actors in a traditional way, into changes and exten-sions to the formal model.

The leader team should indeed propose one (or more) simple formal mod-elling framework(s), possibly FSM based. However, the basic (extensible) modelof the system should be proposed by the leader team both in terms of its require-ment, informally expressed as usual in English language, and formally modeledusing the proposed formal framework.

In such a setting, the project actors, that is the active individuals (or in-stitutions, organisations and even companies) of the project community, maycontribute to the project in a wider range of way with respect to current opensource projects. In addition to the already mentioned activity of reverse engi-neering code into the formal framework, formal methods oriented contributorscould refine and extend the proposed formal model by

– translating the model to other frameworks (possibly developing an automatictranslation or a translation methodology) with the purpose of analysis

– proposing/developing tools and interfaces for formal modelling and verifica-tion

– analysing products using formal techniques and tools;

as well as develop code by implementing the formal model into code. Theseformal methods oriented activities would add to the more traditional activitiesperformed by actors of an open source community:

– addition of new features not included in the informal requirements and in theformal model;

– analysis of products through testing, code inspection, etc.;– products usage and provision of feedback.

Although in this section we have hypothesised some possible new classes of ac-tivities and categories of actors which may develop within the project commu-nity, it is in general difficult to predict all the possible alternative developmentsand which of these may emerge as the most effective and constructive ones.

An important task of the leader team is to address the motivating factorsthat lead to the success of open source projects. The choice of software productby the leader team is definitely an essential factor in attracting membership tothe project and in creating strong motivations to actively participate, especiallyintrinsic motivations, such as

– a personal sense of accomplishment and contribution;– a personal interest in the tools and techniques employed by the project;– satisfaction at a pure creative and artistic level;– sense of belonging to a community, along with a– sharing of knowledge and skills.


We will discuss the aspects related to the choice of software product in Sec-tion 3.1.

The leader team will also need to address extrinsic motivations, such as im-proving one’s technical knowlege base, which may be largely independent of thechoice of software product and are actually more related to the demographicsof the open source community. We will discuss demographic data as well asextrinsic motivations in Section 3.3.

3 Implementation of the Proposal

Critical to the success of this proposal is building an effective team that couldprovide the expertise both across the formal methods and open source domain.Relevant to this is also the choice of software or tool proposed. In this section,we discuss some of these issues to pave the way ahead.

3.1 Choice of software product

To demonstrate the efficacy of formal design and analysis tools, it is certainlyuseful to decide on an appropriate choice of software or tool for this project.There are two possible ways of achieving this.

First, an existing popular tool or utility is redesigned and rebuilt. The ad-vantages of this are the familiarity with requirements. Developers could thenmodel these requirements and analyse for essential properties. The end-productcould then be compared with the existing available versions of the software togauge the benefits of using formal modelling and analysis in terms of fitnessfor purpose, correctness, extensibility and documentation. Such a choice wouldalso be useful in demonstrating the project to the open source community atlarge. A drawback of this option is that it may undermine intrinsic motivationof potential contributors. Redesigning something that already exists may actu-ally not be sufficient to stimulate personal interest and creativity, and may failto build up personal sense of accomplishment and contribution.

The second option could be to conceive an idea from scratch. This wouldbest address intinsic motivations. However, whether it is appropriate or notwould depend on the expertise of the team and how innovative the membersof the team would like to be. Could the use of formal means to design andanalyse software in an open setting facilitate the development of a critical pieceof code that could really be of industrial or personal use? Only time will tellhow innovative and unique the end result for this effort would prove to be.

3.2 Choice of project leadership

Given the relevant interest and expertise of the members of the openCert andFLOSS-FM communities, interested candidates are invited on a voluntary basisfrom this group. As with all such projects, ideal candidates would demonstratesome experience of


– having managed small project teams to success,– having been involved in design and development of software and familiarity

with formal methodologies and tools for such use,– working in academia, industry and open source development, which should

help in dealing with the diverse group of people this project will attract, andfinally,

– public dissemination and reporting, for future academic publications that willhopefully arise from the contributions and experience of this project.

The workshop provides an ideal opportunity to seek volunteers or identifyinterested candidates who could embark on the activity as soon as possible. Incase of interest from more than a single candidate, a quick show of hands couldbe used to decide and elect a leader. On the other hand, a group of people couldbe nominated to serve as a core team that provides leadership at various levels.

3.3 Choice of project members and developers

Studies carried out by the Technical University Berlin (2001), the InternationalInstitute of Infonomics at the University of Maastrict (2002) and the BostonConsulting Group in cooperation with the Open Source Development Networkthe community of those who devote a substantial part of their free time to opensource projects consists of

– 98% of males;– 70% of people aged between 22 and 27;– 60% of IT professionals;– 20% of university students;– 80% university graduates, including 10% PhD.

These results give a useful indicator of the profile of potential project membersand developers. There is no reason however why females and people aged above27 could not be members however. This project should serve as an opportunityto encourage the under-represented in software engineering in general. Membersfrom the developing countries in Asia, Latin America and Africa are particularlyencouraged to find support for this effort and encourage volunteers at all levelsto come forward. Given this, the project is proposed to issue an entirely opencall for participation.

A variety of motivations could be tapped into to attract participation in-cluding

Academic projects and dissertations for those students directly driven byinterested academics. Various modelling, analysis, development and testingtasks could be conceived as exercises and projects for students to work on.All involved parties, including academics, students and institutions wouldbe acknowledged.


Problems and challenges posed to the existing open source community.Open source project who have had members solve similar problems couldbe specifically targeted for invitation to participate and contribute to arelevant aspects of the project.

Learning opportunities for those who are new to formal methodologies andare inclined to develop familiarity and relevant skills. This project couldbe a great opportunity for students and developers alike to get hands onexperience on modelling and analytical tools and techniques, and using themto solve real problems.

A raised public profile of the members involved in the project. Oncethe project makes a successful start, there is no reason why the electronicand print media be kept uninformed of the progress. This should serve as anideal model for useful and effective change in the way software projects arecommissioned and run, and such features should be publicly emphasised.

3.4 Dissemination and deliverables

The project is proposed with the hope of demonstrating the efficacy of formalmethods for an open sourced development and various workings of the projectshould therefore be of interest to the software community and industry at large.Various aspects that would be of interest and their dissemination include:

the formation of the team of members that bring together expertise fromdiverse areas would be of interest to those who wish to initiate such opensource projects. Academic and industrial corporations could take particularinterest. Such information could be published as project reports and papers.

application of formal methods by a distributed, volunteer set of members.Of interest here would be how much of a learning curve do formal methodsprove to be for members and developers who are new to it, and whethersuch projects serve to effectively address this? There is a growing interestin the formal methods community in the teaching and pedagogic styles,and various conferences and events are a good way of disseminating suchinformation [21],[20],[23].

the actual software product that is developed. It would be interestingto see what benefits formal methods bring to the actual design and cor-rectness of a chosen product. This would be of interest to the industry andusers who could be made aware of this using the media and the Internet.

the day-to-day inner workings of the project team members and theproblems they face. An open project blog is proposed that could be ac-cessed by team members to allow them to share their thoughts and feelingsabout the various aspects as the project progresses. Such a blog could serveto be a useful record of the project and the various challenges and problemsit faces. The blog is also a good opportunity for attracting new members tothe project and advertising the achievements.


3.5 Sponsorship and funding

This proposal describes the authors’ ideas which are still in early stages and it ishoped that the proposal will materialise to success. One of the authors’ aims is tounderpin this effort with a dedicated core team that could sustain such activityformally for over a long period of time. This would allow the results of suchan effort to mature and get widespread acknowledgment and acceptance thatit deserves. For this purpose academic and/or industrial sponsorship is sought.A good example of this is the commercial sponsorship provided to the Ubuntuproject [18] by Canonical Ltd. [3], which is a European company founded in2004 employing a hundred or so staff. Similar commercial sponsorships couldbe easier to earn if the proposed project aims to develop a popular, usable toolor utility, possibly something of interest to the industry.

Given the rigorous nature of formal methods and a focus on achieving cer-tifiable standards, our proposed project is potentially attractive to serious at-tention from the academia and the industry alike. Academia is thoroughly in-terested in the uptake of formal methods by the developer community andlooks for ways to introduce them as realisable skills as part of the traditionalcomputer science education. The proposed project promises to lure young de-velopers into using formal methodologies to develop useful software, which isprecisely what the universities strive for. It could therefore potentially serve tobe proof of concept for this purpose. It is hoped that computer science depart-ments and research groups, and individual academics interested in the projectcould support the various aspects of the project highlighted in the previoussection. This could involve anything from hosting project servers to provid-ing technical support to even providing ad hoc training material to familiariseproject participants to concepts and notions underlying formal methods. Thelevel of commitment and involvement is open and negotiable.

Software industry is also invited to actively take part in the success of thiseffort. This involvement is not new as is evident by examples such as the sup-port for OpenSolaris [14] by Sun Microsystems [16], Debian [11] and other opensource software by Hewlett-Packard (HP) [9] and Osmosoft [15] by British Tele-com (BT) [2]. These joint efforts demonstrate how the software industry hashad a positive influence over the creativity and progress of the open sourcecommunity. Such efforts are necessary if compatible and relevant technologiesare to interoperate between open and proprietary standards. Moreover theseare examples of sustainable and successful projects. This proposal calls for anopen invitation for industry groups to forge links with the academic and devel-oper community to incorporate formal and rigorous practices into open sourcesoftware development.

The project team is also encouraged to liaise with other industry and profes-sional bodies both to attract positive attention and highlight the cause set outin the first section of this paper. Some such bodies include the Formal Aspects ofComputing Science (FACS) [6] and the Open Source Specialist Group (OSSG)[13] of the British Computer Society (BCS) [1], the Working Group 2.13 on


Open Source Software [19] of the Technical Committee on Software Theory andPractice [17] of the International Federation for Information Processing (IFIP)[10], European Information Society [5] (considering their recent initiatives [4]for free and open source software activities), the Open Source Initiative [12],the Free Software Foundation Europe [8], and Formal Methods Europe (FME)[7].

References

1. British Computer Society. http://www.bcs.org.2. British Telecom. http://www.bt.com.3. Canonical Ltd. http://www.canonical.com.4. EIS Free and Open Source Software.

http://ec.europa.eu/information society/activities/opensource/index en.htm.5. European Information Society.

http://ec.europa.eu/information society/index en.htm.6. Formal Aspects of Computing Science. http://www.bcs-facs.org.7. Formal Methods Europe. http://www.fmeurope.org.8. Free Software Foundation Europe. http://www.fsfeurope.org.9. Hewlett-Packard. http://www.hp.com.

10. International Federation for Information Processing. http://www.ifip.org.11. Open Source and Linux from HP.

http://h71028.www7.hp.com/enterprise/cache/309906-0-0-0-121.htm.12. Open Source Initiative. http://www.opensource.org.13. Open Source Specialist Group. http://ossg.bcs.org.14. OpenSolaris. http://www.opensolaris.org.15. osmosoft. http://www.osmosoft.com.16. Sun Microsystems Inc. http://www.sun.com.17. Technical Committee on Software Theory and Practice.

http://www.ifip.or.at/bulletin/bulltcs/memtc02.htm.18. Ubuntu. http://www.ubuntu.com.19. Working Group 2.13 on Open Source Software.

http://www.ifiptc2.org/wg-2.13.html.20. Formal Methods in the Teaching Lab Workshop. Formal Methods, Hamilton,

Canada, August 2006.21. Teaching Formal Methods: Practice and Experience. BCS-FACS Christmas Meet-

ing, Oxford Brookes University, UK, December 2006.22. Open source report 2008, 2008. http://www.coverity.com.23. R-J Back, editor. Teaching formal methods to students in high school and intro-

ductory university courses. Formal Methods, Turku, Finalnd, May 2008.24. Peter T. Breuer and Simon Pickin. Approximate verification in an open source

world. Innovations in System and Software Engineering, 4(1):87–105, April 2008.Springer-Verlag.

25. Martin Michlmayr. Quality improvement in volunteer free software projects: Ex-ploring the impact of release management. In Marco Scotto and Giancarlo Succi,editors, Proceedings of the First International Conference on Open Source Sys-tems, pages 309–310, Genova, Italy, 2005.


26. Martin Michlmayr, Francis Hunt, and David Probert. Quality practices and prob-lems in free software projects. In Marco Scotto and Giancarlo Succi, editors,Proceedings of the First International Conference on Open Source Systems, pages24–28, Genova, Italy, 2005.

27. Moreno Muffatto. Open Source — A Multidisciplinary Approach. Imperial CollegePress, 2006.

28. P Neumann. Robust open source software. Communications of the ACM,41(2):128, 1998.

Certification of Technical Quality of Software

Products

Jose Pedro Correia and Joost Visser

Software Improvement Group, The [email protected], [email protected]

Summary. In this paper we propose a method for certification of technical qualityof software products. The certification method employs a layered model of technicalquality, based on the ISO/IEC 9126 international standard for software productquality. This model was developed in the context of software assessments conductedon commercial software systems over the course of several years. Using the layeredquality model as a basis, we define a three-phase appraisal method that ends incertification of a software product at one of five possible levels. We illustrate thecertification method by providing details of its application to twelve open sourcedatabase management systems and five open source web servers.

1 Introduction

Previously, the Software Improvement Group (SIG) has developed a methodfor measuring the quality of software products in terms of the ISO/IEC 9126standard [8]. It employs a small number of source code metrics, which areaggregated and mapped to quality characteristics in a manner that directlyrelates to the standard. The model was developed in the course of deliveringIT management consultancy services [4, 13]. In particular, it has proven to bea pragmatic instrument in providing fact-based rapid estimates of technicalquality of scores of large software systems.

In this paper, we explore the possibility of using the previously developedmodel for certification of software products. We focus on product certification,motivated by the current lack of standards and procedures for this purpose.We ask ourselves whether the model can be used to provide the necessarycriteria and standards. And if yes, how exactly?

We can not disclose measurement data for the systems of our clients, soinstead we have applied our method to a series of open source software (OSS)systems. These are listed in Table 1, ordered by their overall quality score. Inthe sequel, we use them to illustrate our certification approach, and we discussin some detail the measurement data and intermediate scores obtained.

36 Jose Pedro Correia and Joost Visser

System Version Functionality Main PLs LOC Rating

Axion 1.0-M2 (2003-07-11) DBMS Java 18921 ⋆ ⋆ ⋆⋆

H2 1.0.69 (2008-03-29) DBMS Java 72102 ⋆ ⋆ ⋆

CSQL 1.2 beta (2007-12-27) DBMS C/C++ 14830 ⋆ ⋆ ⋆

SmallSQL 0.19 (2007-07-31) DBMS Java 18402 ⋆ ⋆ ⋆

JalistoPlus 2.0 M2 (2008-04-11) DBMS Java 21943 ⋆⋆

Derby 10.3.2.1 (2007-12-10) DBMS Java 307367 ⋆⋆

Jaminid 0.99 (2006-04-21) Web Server Java 1120 ⋆⋆

HSQLDB 1.8.0.9 (2007-09-07) DBMS Java 65378 ⋆⋆

SQLite 3.5.8 (2008-04-16) DBMS C 69302 ⋆⋆

AOLServer 4.5 (2006-06-27) Web Server C 45344 ⋆⋆

Apache 2.2.8 (2008-01-19) Web Server C 203829 ⋆⋆

Canopy 0.2 (2007-09-12) Web Server C 15570 ⋆⋆

Tomcat 6.0 (2008-01-17) Web Server Java 164199 ⋆⋆

PostgreSQL 8.3.1 (2008-03-17) DBMS C 497400 ⋆⋆

MySQL 5.0.51a (2008-01-11) DBMS C/C++ 843175 ⋆⋆

602SQL 2008-04-18 DBMS C/C++ 274938 ⋆

Firebird 2.1.0 (2008-04-18) DBMS C/C++ 357537 ⋆

Table 1. OSS systems appraised, ordered by overall quality score.

The paper is structured as follows. In Section 2, we provide motivation andbackground to our work by discussing the position of software product qualitywith respect to other software quality perspectives. In Section 3, we discussdesign choices and constraints for a possible certification method. In Section 4,we summarize our previously developed model and its relation to ISO/IEC9126. In Section 5, we propose a particular method for certification in whichthis model is employed. We describe the method in terms of its actors, steps,and deliverables. In Section 6, we discuss the application of the model to theOSS systems mentioned in Table 1. In Section 8, we discuss related work. Weconclude in Section 9 with a discussion of contributions and future work.

2 Motivation

To motivate our proposal for a certification method for software product qual-ity, we provide a brief discussion of traditional perspectives on software qualityand offer an explanation for the current lack of product certification methods.

2.1 Traditional perspectives on software quality

In IT, quality is mostly approached via three angles: process, people, andprojects. These are what could be called the environmental characteristics ofa given software product, that is, the factors that determine its developmentconditions and thus are expected to influence its final quality. For each of

Certification of Technical Quality of Software Products 37

SAP xApps?(compatibility)

Process(organizational)

Project(individual)

People(individual)

Product

CMMI(Scampi)

Prince2

SPICE

MCP(Microsoft)

TMap

PMP

Misra(coding)

Fig. 1. Triangular representation of well-known standards and certifications in IT.

these perspectives, methods exist to improve and maintain quality, often withassociated standards and certifications (Figure 1).

Regarding the software process, the most well-known certifications areCMMI (Capability Maturity Model of the Software Engineering Institute1)and SPICE (Software Process Improvement and Capability dEtermination,linked to the ISO/IEC 15504 standard on IT Process Assessment). These cer-tifications are awarded at the level of entire organizations or their departmentsand deal with the quality of the software production process.

Certification of people concerns quality in the sense of skills and knowl-edge of the individuals that carry out the software production process. Suchcertificates are awarded after one concludes a training course. In some, butnot all cases, an exam needs to be passed. Examples include the MicrosoftCertified Professional, dealing with skills for particular technologies of thesoftware giant, or TMap certification for testers.

With regard to the quality of the projects by which the software produc-tion process is structured, certifications can be obtained regarding projectmanagement methodologies, such as PRINCE2 (PRojects IN Controlled En-vironments of the UK Office of Government Commerce, OGC) or PMP(Project Management Professional of the Program Management Institute,PMI). Again, these certificates are awarded to individuals after appropriatetraining and exams.

Thus, certification is available for the software production process itself,the people that carry it out at the technical level, and the people that managethe projects by which the process is structured. But what about the result ofthe software production process? What certification possibilities exist for thesoftware product?

1 SEI uses the term ”Class A Appraisals” instead of ”certification”


2.2 State of the art in software product certification

Outside IT, product certification is ubiquitous. Some products receive certifi-cation on a piece-by-piece basis, such as industrial plants or the foundationsof a house. Other products are certified on the basis of sampling, such as elec-trical plugs. The majority of the parts from which cars are assembled havebeen certified in some way.

Perhaps surprisingly, certification of software products is not a commonlyaccepted practise [5]. In fact, the possibilities of software product certificationare very limited. The MISRA-C standard has been adopted in the automo-tive domain to enforce suppliers of embedded software to abide by certainrules for coding style. In the realm of implementation of Enterprise ResourcePlanning (ERP) and Customer Relationship Management (CRM) packages,the possibility exist of certifying the compatibility of custom code with themain product. This means for instance, that only SAP-endorsed technologieshave been used for the ERP integration. Beyond such technology-specific orvendor-specific certificates with limited scope, software product certificationis absent from current practise.

2.3 No certification without normative standard

Can we identify any fundamental reasons why software product certificationis absent from current IT practises?

The very notion of certification presupposes the existence of a standardagainst which the object of certification can be measured and evaluated. Atthis moment, no widely accepted standard sets concrete, actionable norms forsoftware product quality [5].

The closest thing is the ISO/IEC 9126 international standard for soft-ware product quality [10]. This standard answers the question of how themulti-faceted concept of software product quality can be defined. By breakingthis concept down into 6 characteristics, which are further split into 27 sub-characteristics (see Figure 2), the ISO/IEC 9126 provides a terminologicalbasis for thinking and communicating about software quality. In the technicalreports that accompany the ISO/IEC 9126 standard, some metrics are sug-gested to measure each sub-characteristic. Unfortunately, no concrete thresh-olds are given for these suggested metrics, nor do their definitions clarify howto measure them in practical situations (for a more elaborate critique see [8]).

A related standard, the ISO/IEC 14598, defines an evaluation process ofsoftware product quality, including guidelines on how to plan and design theevaluation, as well as about its execution. This is useful as a basis to definea certification process, but does not solve the issue of how to measure soft-ware product quality or how to compare measurement values to a normativestandard.

analysabilitychangeabilitystabilitytestability

maintainability

maturityfault tolerancerecoverability

reliability

external and internal quality

suitabilityaccuracy

interoperabilitysecurity

functionality

adaptabilityinstallabilityco-existencereplacability

portability

understandability

learnabilityoperability

attractiveness

usability

time behaviour

resource utilisation

efficiency

Fig. 2. Breakdown of the notions of internal and external software product qualityinto 6 main characteristics and 27 sub-characteristics. The 6 so-called compliancesub-characteristics of each of the 6 main characteristics have been suppressed in thispicture. In addition, ISO/IEC 9126 provides a breakdown of the notion of ‘qualityin use’ of a software product into four sub-characteristics.

3 Towards certification of software products

When proposing a method for software product certification, several designdecisions need to be made. We first discuss what the precise target of certifi-cation would be. Then we discuss prerequisites on a certification method tomake it viable for broad acceptance in the IT industry.

3.1 Possible targets of product certification

The target of certification is the quality of the software product. But whichperspective on quality should be taken into account? On first consideration,several perspectives may seem likely candidates:

Functionality : Does the software product satisfy its functional requirements?Performance: Does the product perform its required operations fast enough?Usability : Is using the product easy and effective?

These aspects indeed represent valid views on software product quality. Infact, in the ISO/IEC 9126 quality model (see again Figure 2), these aspectscan be recognized as the suitability, efficiency (time behaviour), and usabil-ity (operability) characteristics of internal and external quality, and as theeffectiveness characteristics of quality-in-use.

Note, however, that all of the aforementioned aspects are tightly connectedto a system’s functionality and to the perspective of the end-user. This meansthat only systems that share certain functionality could be certified against ashared norm, and that a norm against which to certify would only be appli-cable to a limited set of systems.

In fact, functional quality aspects may be problematic as a target forcertification for several reasons:

• Functional requirements may be unavailable, unclear, or instable.



• Functional requirements are rarely shared across systems.• Functional requirements that are shared across systems typically concern

only a subset of the functionality, such as particular interoperability fea-tures, GUI guidelines, or performance demands.

Due to these reasons, certification methods that target functional quality nec-essarily have restricted applicability.

In this paper, we choose technical quality as an alternative target of certifi-cation. The technical view on a software product’s quality concerns how well-constructed it is. In terms of the ISO/IEC 9126, the focus of technical qualityis primarily on the maintainability characteristic and its sub-characteristics.Other characteristics and sub-characteristics, such as reliability and portabil-

ity, may also play a role.Technical quality of a software product is interesting, not from an end-

user’s perspective, but from the perspective of those who maintain and modifythe source code. The technical quality of a software product determines howdifficult it is to keep the system evolving to remain aligned with the continuouschanges in the functional requirements, whatever these are. In the longer term,technical quality may actually be the largest contributor to the total cost ofownership of a software system, because software with high technical qualitycan evolve with low cost and low risk to keep meeting functional and non-functional requirements.

3.2 Requirements for a certification method

Based on the preceding discussion, some prerequisites and desired traits canbe laid out for a software product certification method, as we envision it.

• The method should target technical quality.• The method should conform to accepted standards for software product

qualty, such as ISO/IEC 9126 (quality model) and ISO/IEC 14598 (qualityevaluation procedure).

• The method should be based on objective evaluation criteria and clearthresholds.

• The method should follow a transparent and repeatable procedure.• The method should have wide applicability.

In the sequel we first describe the quality model we developed previouslywhich conforms with ISO/IEC 9126 and sets clear criteria and thresholds fortechnical quality. Then we propose a certification process that conforms toISO/IEC 14598 which is transparent and repeatable.

4 Summary of the quality model

The SIG has developed a layered model for measuring and rating the tech-nical quality of a software system in terms of the quality characteristics of

system property e.g. complexity

ISO/IEC 9126 (sub-)characteristice.g. changeability

source code measuree.g. cyclomatic complexity

influences

indicates

can be measured by

can be caused by

Fig. 3. The relation between source code metrics and system sub-characteristics ofmaintainability, as established by the SIG model.

ISO/IEC 9126 [8]. The layered structure of the model is illustrated in Fig-ure 3. Source code metrics are used to collect facts about a software system.The measured values are combined and aggregated to provide information onproperties at the level of the entire system, which are then mapped into higherlevel appraisals that directly relate to the ISO/IEC 9126 standard.

To aggregate metrics at the source code level to properties at the systemlevel, we make use of so-called quality profiles. As an example, let’s take a lookat how unit complexity is calculated. First the McCabe complexity indexis calculated for each code unit (where a unit is the smallest piece of codethat can be executed and tested individually, for example a Java methodor a C function). The values for individual units are then aggregated intofour risk categories, as indicated in the following table (following a similarcategorization of the Software Engineering Institute):

mcc Risk evaluation1-10 without much risk11-20 moderate risk21-50 high risk> 50 very high risk

For each category, the relative volumes are computed by summing the linesof code of the units of that category and dividing by the total lines of code inall units. These percentages are finally ranked using the following thresholds:

maximum relative locrank moderate high very high++ 25% 0% 0%+ 30% 5% 0%o 40% 10% 0%- 50% 15% 5%-- - - -

Other properties have similar evaluation schemes relying on different catego-rization and thresholds. Such quality profiles have as advantage over otherkinds of aggregation, such as taking the average, that sufficient information isretained to make significant quality differences between systems detectable.



For the appraisal of test quality, the model does not rely on static sourcecode analysis only. Instead we apply a structured review which takes into ac-count the use of testing frameworks, estimates of the level of coverage achieved,and the amount of test documentation available.

The rating of system properties is first done separately for each differenttechnology, and subsequently aggregated into a single technology-independentproperty rating by weighted average according to each technology’s relativevolume in the system.

Property ratings are mapped to ratings of sub-characteristics, followingthe relations summarised in the following table:

ISO

9126

main

tain

ability

properties

duplica

tion

test

quality

unit

com

ple

xity

unit

size

volu

me

analysability × × ×

changeability × ×

stability ×

testability × × × ×

For example, duplication is mapped onto both analysability and changeabil-ity. For each sub-characteristic a straightforward averaging approach is taken.Finally, all sub-characteristic ratings are averaged to provide the top main-

tainability rating.

5 The certification method

On top of SIG’s quality model, we now propose an appraisal method forcarrying out software product certification. The method consists of three steps,namely scoping, measurement and rating. Depending on the appraisal results,the software product will be certified at one out of five possible levels ofquality. These are represented using a five stars system, with the followinginterpretation:

rating quality⋆ ⋆ ⋆ ⋆ ⋆ excellent

⋆ ⋆ ⋆⋆ good⋆ ⋆ ⋆ fair

⋆⋆ poor⋆ very poor

We start by explaining the roles of various actors in the certification pro-cedure, and follow by describing the procedure itself.


certification client

certification institute

system producer systemsourcecode

certification laboratory

certificationboard certificate

Fig. 4. Product certification roles.

5.1 Roles

Software product certification is carried out through a procedure where tasksand responsibilities are divided over various players. The roles of the variousactors in the certification procedure are depicted in Figure 4.

The system producer is the organization that has built the software prod-uct for which certification is sought. This organization is responsible for mak-ing the source code and possibly other artefacts available to the certificationinstitute. In case of open source software, this is the community of program-mers that develops, maintains, and releases the software. For closed sourcesoftware, this is the organization that ordered the system to be built and thatholds property rights over the software.

The certification client is the organization that seeks certification of thesoftware product. In the case of closed source software, this is typically theorganization that has ordered the system to be built or that is considering toacquire the system. In case of open source software, this may be an organiza-tion that intends to adopt the software as application to support its businessprocesses, as library in application development, or for other purposes. Thecertification client may work with the certification institute to determine thedesired scope of the certificate.

The certification institute oversees the certification procedure and issuesthe certificates. The certification institute is responsible for brokering the rela-tion between certification client, system producer, and certification laboratory,and for performing the scoping and rating steps.

The certification laboratory carries out the measurement step, in whichmeasurement values are produced for all system units. The laboratory mayalso assist in defining the certification scope, if required.

The certification board provides oversight over the entire certification pro-gram and offers arbitration in case of disputes about application of the certi-fication norms.


Scope Measure Rate

Request Scope Result

Create scopedefinition

andconfigure

tools

Run analysistools andvalidateresults

Appraisemeasuredvalues and

create report

Publish

Issue

Issue thequality

certificate

Fig. 5. Steps of the certification procedure.

5.2 Procedure

The certification procedure leads to attribution of a quality certificate in threesteps, as illustrated in Figure 5.

Scope

In the first step, the scope of the certification study is determined. As a resultof this step, an unambiguous description will be available of which softwareartefacts are covered by the evaluation.

This scope description includes the release version of the software system,a listing of file names, dates, and sizes, and a characterisation of the technol-ogy footprint of the system (which programming languages, database man-agement system, persistence and GUI frameworks, configuration languages,communication protocols). When appropriate the description will also sep-arate documentation from code, test code from production code, generatedcode from manually written code, and library from application code.

Measure

In the second step, a range of measurement values is determined for the soft-ware artefacts that fall within the evaluation scope. Each measure is deter-mined automatically by processing the software artefacts with an appropriatealgorithm.

Rate

In the third step, the raw metric values obtained in the measurement step areaggregated, weighted, combined, and subsequently compared against target


Establishevaluation

requirements

Establish purpose of evaluation

Identify types of products

Specify quality model

Specify theevaluation

Select metrics

Establish rating levels for metrics

Establish criteria for assessment

Design theevaluation

Produce evaluation plan

Execute theevaluation

Take measures

Compare with criteria

Assess results

ISO/IEC 9126

SIG Quality Model

Scope

Measure

Rate

Issue

Any software product

Certification

ISO

/IE

C 1

45

98

Fig. 6. Correspondance of our certification method to the ISO/IEC 14598 standard.

values in order to determine quality sub-scores and final score for the systemunder evaluation.

The result consists of a layered set of appraisals, namely the appraisal forthe only characteristic now considered, maintainability, traceable to the sub-characteristics’ appraisals which in turn are traceable to property appraisalsand finally those can be related to the source code measurements that wereconsidered.

Appraisals are represented in a 5 star system, directly correspondent to the++,+,o,-,-- system used in the SIG quality model, being 1 star representativeof very poor quality and so forth. Internally, a fractional value is used in orderto maintain precision in the calculations.

Issuance

Finally, based on the rating results, a certificate is issued. The certificate ispublished in an online registry if the certification client so wishes.

5.3 Compliance with ISO/IEC 14598

The ISO/IEC 14598 international standard for software product evaluation [9]provides an overview of software product evaluation processes and is intendedto give guidance and requirements for software evaluation.

Figure 6 depicts the overal structure of the software evaluation process ac-cording to this standard and highlights its correspondance to the certificationprocedure proposed in this paper. The left hand side of the picture shows thevarious evaluation phases and the constituent evaluation steps defined by thestandard. The right hand side indicates how each step is made concrete by


Unit testing Functional testing

System Framework Coverage Framework Coverage Documentation Appraisal

Axion JUnit 81% JUnit unknown almost none ⋆ ⋆ ⋆⋆

H2 custom 83% custom high none ⋆ ⋆ ⋆⋆

CSQL - - none high none ⋆⋆

SmallSQL - - JUnit 79% almost none ⋆ ⋆ ⋆

JalistoPlus JUnit low JFunc low none ⋆⋆

Derby JUnit 71% custom high almost none ⋆ ⋆ ⋆

Jaminid - - - - none ⋆

HSQLDB JUnit low custom unknown yes ⋆⋆

SQLite - - custom very high almost none ⋆ ⋆ ⋆

AOLServer - - rudimentary almost none almost none ⋆

Apache - - custom high good ⋆⋆

Canopy - - - - none ⋆

Tomcat JUnit very low - - almost none ⋆

PostgreSQL - - custom high good ⋆⋆

MySQL custom very low custom high extensive ⋆ ⋆ ⋆

602SQL - - - - none ⋆

Firebird - - TCS & QMTest high extensive ⋆ ⋆ ⋆

Table 2. Ratings of test quality based on structured review.

our certification method. For example, the concrete purpose of evaluation iscertification. The metrics, rating levels, and criteria are chosen in accordanceto the SIG quality model. The evaluation design is carried out in the scopingstep of our procedure, and the execution of the evalation are covered by ourmeasurement, rating, and issuance steps.

6 Application to open source software

To put the proposed certification method to the test, we conducted appraisalsof some well-known open source systems. For now, 12 relational databasesystems, including MySQL and PostgreSQL have been examined, as well as5 web servers, including Tomcat and Apache HTTP Server. The results arepresented in this section, preceded by some remarks.

6.1 Systems under study

We were looking for systems with similar functionality, if possible of differentvolume and using different languages. We selected projects from two func-tionality groups, namely database systems and web server applications. Somesystems were included for their popularity and the remaining by doing a searchon SourceForge2. The latest release versions, at the time of analysis, were se-lected for each system. An overview was already presented in Table 1, showingsystems ranging from very small to large and covering the programming lan-guages of Java, C and C++.

2http://sourceforge.net


Syst

em

Maintaina

bility

Analy

sability

Changea

bility

Sta

bility

Tes

tability

Duplica

tion

Tes

tquality

Com

ple

xity

Unit

size

Volu

me

Axion ⋆ ⋆ ⋆⋆ (+0.54) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆

H2 ⋆ ⋆ ⋆ (+0.08) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆

CSQL ⋆ ⋆ ⋆ (−0.13) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

SmallSQL ⋆ ⋆ ⋆ (−0.38) ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

JalistoPlus ⋆⋆ (−0.54) ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆

Derby ⋆⋆ (−0.54) ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆

Jaminid ⋆⋆ (−0.63) ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

HSQLDB ⋆⋆ (−0.70) ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

SQLite ⋆⋆ (−0.79) ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

AOLServer ⋆⋆ (−0.83) ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

Apache ⋆⋆ (−1.00) ⋆ ⋆ ⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆

Canopy ⋆⋆ (−1.04) ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

Tomcat ⋆⋆ (−1.08) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆⋆

PostgreSQL ⋆⋆ (−1.08) ⋆⋆ ⋆⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆

MySQL ⋆⋆ (−1.16) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆

602SQL ⋆ (−1.21) ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆

Firebird ⋆ (−1.25) ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆ ⋆⋆

Table 3. Appraisals of technical quality for the selected OSS systems, ordered byoverall score.

6.2 Conducting the appraisals

The scoping of the mentioned systems was done by us, either by inspectingthe available documentation, browsing through the source code or using someautomatic heuristics (for example searching for specifc patterns in files to de-termine and exclude the generated code). This makes the process less accuratethan in the ideal situation, when this is done jointly by the certification in-stitute, the certification client and the system producer. On average we spentabout 4 hours on the scoping step for each system.

Source code measurements were performed using SIG’s software analysistoolkit. The scope definition served as the basis for the configuration of thetoolkit. To conduct the rating step, the measurement results were fed intoSIG’s rating engine. This second tool implements a subset of the SIG qualitymodel. The structured review of test quality is summarized in Table 2.

6.3 Results

The appraisal values can be found in Table 3 ordered by overall maintainabilityvalue. The sorting is done according to the fractional representation of qualityappraisals used internally by the rating tool, thus systems with the samenumber of stars do have different internal values. These are shown for themaintainability appraisal and range from -2 (one star) to 2 (five stars).


Java C/C++ C

*****

****

***

**

*

Fig. 7. Boxplot of the maintainability values per language. The Y axis is dividedinto 5 sections, corresponding to the star system.

6.4 Observations

The overall technical quality of the systems, as appraised by our method,is low. A rating of three stars is considered to represent medium quality.By inspecting the results one can observe that one system is rated as good(Axion), three as medium (H2, CSQL, SmallSQL), and most systems wereappraised as having (very) poor quality.

We do not claim this sample to be statistically significant or representativeof the population of open source systems, so it would be interesting to furtherinvestigate some trends observed here. For example, one of the most strikingobservations is that almost all systems rank very low regarding unit size andrelatively low regarding complexity. This could be due to the model being toostrict, but the definition of these particular properties, as with the others,was done based on our experience with proprietary systems, and for those abroader distribution of values is observed.

In Figure 7 one can observe the boxplots of the maintainability valuesper main programming language. The main conclusion one can take fromthis chart is that Java systems tend to rank higher. Although there are someoutliers, the bulk of these systems rank around the border between two andthree stars, whereas for the other languages the bulk ranks in the two starsarea but closer to the border between one and two stars.

7 Relation to other quality instruments

Software product certification is a new instrument for software quality man-agement that can be used in combination with other instruments.

Various kinds of software testing, such as unit testing, functional testing,integration testing, and acceptance testing are essential for software product


quality, both functional and technical. Certification does not replace testing,but operates on a higher level, is less labour-intensive, and can be performedindependently. Note that certification also takes test quality into account.

Methodologies for software process improvement (SPI), such as the capa-bility-maturity model (CMM) concern the production process, rather thanthe product. SPI works under the assumption that better processes lead tobetter products, which is true to a limited degree. Product certification con-cerns only the product, independently of its organizational context. These twoinstruments can thus be used independently or simultaneously.

A software risk assessment [4] is an in-depth, one-off investigation into thetechnical quality of a software system as well as into the strategic risks that itharbours. Each assessment is necessarily specific to the investigated softwaresystem as well as to its organizational context. By contrast, software productcertification is not situational and enables objective comparison to commonnorms and standards applicable across systems.

Monitoring a software system or an entire software portfolio [12] is a con-tinuous activity aimed at real-time progress tracking and detection of prob-lems as they occur. Software monitoring provides increased control over thedevelopment and maintenance processes. Software product certification is alow-frequency activity providing control at the level of governance rather thenat the tactical level.

Software benchmarking consists of comparing software products againsteach other according to desired characteristics [2]. This can be used to ranka system with respect to a group of peers, thus differing from certificationwhere one is interested in establishing a norm to which to compare systems.

8 Related work

For a discussion of work related to the employed quality model we refer toHeitlager et al [8]. Here we briefly discuss work related to our certificationmethod. A more elaborate discussion of various approaches to software certi-fication is provided by Fabbrini et al [5].

Certification of functional quality

To our knowledge, no comprehensive proposals have been made so far forcertification methods that target technical quality. However, some proposalshave been made for software product certification targeting functional quality.

Heck et al [7] have developed a method for software certification wherefive levels of verification are distinguised. At the highest level, the softwareproduct is verified using formal methods where not only properties are provenabout an abstract model, but about the software itself. To date, one certificatehas been awarded, on the one-but-highest level.

ISO/IEC 9126 lists security as one of the subcharacteristics of functional-ity. The most well-known standard regarding security is the ISO/IEC 15408


standard on evaluation of IT security criteria [11] which has also been pub-lished under the title Common Criteria for Information Technology Security

Evaluation. This standard does not specify concrete security requirements.Rather, it defines a framework for specification, implementation, and evalua-tion of security aspects.

Quality assessment methodologies

Various methodologies have been proposed for the assessment of open sourceproducts, including OSMM [6], QSOS [1] and OpenBRR [14]. A comparisonof the latter two can be found in [3]. These methods mainly focus on the com-munity contribution, activity and other “environmental” characteristics of theproduct. Although these approaches usually include assessment of technicalquality, no concrete definition of measurements or norms are provided.

Open source quality research

Currently there are several research projects related to quality of open sourcesoftware, e.g. FLOSSMetrics, QualOSS, or SQO-OSS 3. Each of these threeprojects aims to provide a platform for gathering information regarding opensource projects and possibly to provide some automated analysis of quality.

9 Concluding remarks

In this paper we motivated the need for certification for software products. Weidentified technical quality (how well the system is built) as the appropriatetarget, and formulated further requirements for a certification method.

We presented our certification method, based on a previously developedquality model which relates to the ISO/IEC 9126 standard for software prod-uct quality. The model provides objective evaluation criteria and is widelyapplicable because it is programming-language independent. The certificationprocedure itself conforms to the ISO/IEC 14598 standard.

We illustrated our certification method by applying it to a group of OSSproducts. The conclusion from applying certification to the OSS systems isthat technical quality, especially length and complexity of units, tends to below. Of course, this does not imply that functional quality of these systems,as experienced by end users, is low as well.

9.1 Future work

We are currently starting to apply the certification method to closed sourcesystems in our consultancy practise. Also, we intend to apply the methodto more open source systems, such as operating system kernels and office

3http://flossmetrics.org, http://www.qualoss.eu, http://www.sqo-oss.org


applications. We are collaborating with the Software Quality Observatory forOpen Source Software (SQO-OSS) to make the certification results for OSSsoftware available to the community.

The certification method introduced in this paper is light-weight, prag-matic, and broadly applicable. Over time, we expect to develop it into anincreasingly sophisticated method to meet rising demands. We intend to vali-date and improve the method in various ways. For example, we are currentlyconducting benchmark studies and statistical analysis to provide further cal-ibration of the underlying quality model [2]. We also intend to broaden therange of source code metrics and evaluated quality characteristics, includingfor example reliability.

References

1. Atos Origin. Method for qualification and selection of open source software(QSOS), version 1.6, April 2006.

2. J.P. Correia and J. Visser. Benchmarking technical quality of software products.To appear, 2008.

3. J.-C. Deprez and S. Alexandre. Comparing assessment methodologies forfree/open source software: OpenBRR and QSOS. In PROFES, 2008.

4. A. van Deursen and T. Kuipers. Source-based software risk assessment. In Proc.Int. Conf. Software Maintenance, page 385. IEEE Computer Society, 2003.

5. F.Fabbrini, M.Fusani, and G.Lami. Basic concepts of software certification. InS.Gnesi, T. Maibaum, and A. Wassyng, editors, Proc. First Int. Workshop onSoftware Certification (CertSoft 2006), Software Quality Research Laboratory.McMaster University, Canada, 2006. Report no. 37.

6. B. Golden. Making open source ready for the enterprise: The open source ma-turity model. Whitepaper available from www.navicasoft.com, 2005.

7. P.M. Heck and M.C.J.D. van Eekelen. The LaQuSo software product certifica-tion model: (LSPCM). Technical Report 08-03, Tech. Univ. Eindhoven, 2008.

8. I. Heitlager, T. Kuipers, and J. Visser. A practical model for measuring main-tainability. In 6th Int. Conf. on the Quality of Information and CommunicationsTechnology (QUATIC 2007), pages 30–39. IEEE Computer Society, 2007.

9. International Organization for Standardization. ISO/IEC 14598-1: Informationtechnology - software product evaluation - part 1: General overview, 2001.

10. International Organization for Standardization. ISO/IEC 9126-1: Software en-gineering - product quality - part 1: Quality model, 2001.

11. International Organization for Standardization. ISO/IEC 15408: Informationtechnology - security techniques - evaluation criteria for IT security, 2005.

12. T. Kuipers and J. Visser. A tool-based methodology for software portfoliomonitoring. In Mario Piattini et al., editors, Proc. 1st Int. Workshop on SoftwareAudit and Metrics, (SAM 2004), pages 118–128. INSTICC Press, 2004.

13. T. Kuipers, J. Visser, and G. de Vries. Monitoring the quality of outsourcedsoftware. In J. van Hillegersberg et al., editors, Proc. Int. Workshop on Tools forManaging Globally Distributed Software Development (TOMAG 2007). Centerfor Telematics and Information Technology, Netherlands, 2007.

14. OpenBRR.org. Business readiness rating for open source, request for comment1, 2005.

Formal Methods for Open Source Components Certification

Alexey Khoroshilov1 and Vadim Mutilin2 1 Institute for System Programming of the Russian Academy of Sciences,

109004, 25, B. Kommunisticheskaya, Moscow, Russia [email protected]

2 Institute for System Programming of the Russian Academy of Sciences, 109004, 25, B. Kommunisticheskaya, Moscow, Russia

[email protected]

Abstract. Open source development model provides great level of flexibility and the strongest value to end-users. Independent development of small components, distributed and continuous improvement process, flexible relations with other components form a basis for the success of the model. At the same time these specialities have some negative influence upon the quality assurance processes. The paper focuses on bugs related to violations of implicit restrictions on intercomponent interactions in the context of open source projects. We consider how formal methods can help with this problem and propose an approach to automate detection of such bugs. The approach is based on the open source static analysis tool BLAST, which implements counterexample-guided automatic abstraction refinement for verification of programs written in C programming language. We are working on application of the approach to one of the most successful open source project - Linux kernel. We identify and formalize known problems in interactions between drivers and Linux kernel as verification rules. Then our verification toolset can automatically detect instances of these problems in source code of drivers. We are aiming at developing a set of verification rules as complete as possible, which will allow certification of device drivers compatibility with kernels of certain versions and configurations.

1 Introduction

Open source software gains in popularity among both home and business users. The leading research companies predict further open source software growth. So IDC [1] states Linux, which initially was mostly deployed for infrastructure-oriented workloads (such as print and file services, DNS serving, DHCP and HTTP), extends to server business-oriented workloads including things like ERP, CRM, database applications, and line-of-business solutions. The same report forecasts “that spending on software related to Linux server platforms is on a compounded annual grow rate of 35.7 percent from 2006 to 2011”. Another report of Gartner [2] predicts ”By 2012, more than 90 percent of enterprises will use open source in direct or embedded forms”.

53

Analysts give a number of reasons for success of open source software. Availability of source code to anyone for analysis and modification allows software developers:

- to easily build customized solutions; - to reuse a lot of existing functionality; - to investigate any problems occurred in details without addressing the original

developers. End-users become protected from vendor lock-in and are able to select local

companies for maintenance and improvement. If any specific requirements appear, they should not wait while a vendor wishes to implement them because there is a possibility to hire alternative developers. Also, open source software has rather small barrier to entry and reduced risks to fail in the beginning. Another very important aspect is that open source development model provides a fair basis to join efforts of many stakeholders for development of common solutions.

Of course, far from all open source projects are successful. Quite the contrary, only a small number of them scores a success, which means building a strong community of users. But the most popular open source projects such as Mozilla Firefox and Linux, OpenOffice.org and Eclipse, Apache and MySQL provide more cheap and quality alternative to many proprietary analogues.

The basis of successful open source projects is open source development model. In the next section we consider specialities of the model and, in particular, the quality assurance methods used. Then we discuss how formal methods can help to improve quality of open source projects. Section 4 demonstrates our approach of application of formal methods to one of the most successful open source project - Linux kernel. In the last section, we summarize the discussion and consider future possibilities to build open source software certification using formal methods.

2 Open Source Development Model

Let us consider open source software development model, which is widely used across a lot of successful projects already reached the bazaar phase [3]. This model differs from the proprietary one in many aspects. If proprietary development models are centralized ones, the open source model is much more distributed. Of course it does not mean open source model is not centralized at all. Modification of an official source code repository of an open source project is not available to everyone. Such rights are usually given to proved developers only. Proposals from all other developers have to pass through code review process fulfilled by group of experts responsible for integrity and quality of the project. Moreover pair review process is mandatory for all developers in many open source projects. At the same time any developer can modify his local copy of the source code repository to improve, test and even distribute by himself.

Also release management is typically leaded by one person. But all decisions are discussed publicly and open for all stakeholders. If someone disagree with a decision


54 Alexey Khoroshilov and Vadim Mutilin he or she always has a way to implement own preferences as an alternative release or a fork.

Of course, such way is not optimal for both the developer and the project. If the developer keeps his modifications out of the official repository, he has to maintain compatibility with changes in the main line. Also, if the developer proposes his modifications to the project, he will be able to get feedback from experts in the area suggesting the most suitable and effective solutions. The project is interested to include all useful patches into the official repository because it usually wants to provide all required functionality to end-users out of box and to support its development.

On the other hand delays with acceptance of patches to the official version and appearance of independent variations of a project is inevitable for many reasons. The main project is interested in acceptance of code, which solves problems of a group of users. That is why the project may ask to generalize the proposed solution to make it useful for many users if experts believe the solution targets a local problem of the developer only.

There are also other reasons. If the developer has access to a part of platform and configurations supported by the project his code may be incorrect for the rest of the configurations and requires corresponding improvements. If the code does not comply with the quality or style standards of the project it can be rejected too. Sometimes some legal investigation required before acceptance of the code.

Distributed nature of the open source development model leads to more modular architecture of open source software. On the one hand there is a practice to detach all independent functionality to a separate open source project. On the other hand even internal structure of open source projects is organized in more modular manner. One of the reasons is that the code is read by many experienced developers which assists to its structurization and accurate presentation. Importance of modularity and extensible design for success of open source projects is emphasized by researches [3] and confirmed by empirical data [4].

Quality assurance in open source development model significantly depends on two factors: code review and beta testing.

Availability of the code allows anyone to analyze it. If a project has strong community of interested developers this possibility leads to intensive code review process. Since everyone looks at the code from his own point of view and from his own experience the effect of “many eyes” [5] allows to detect a number of bugs. Of course, it does not allow to detect all the bugs [6] since only a small number of core developers understand interdependences between different components and thus can detect difficult-to-find and non-trivial bugs. Small number of the experienced eyes has a good chance to overlook some bugs.

Another principle of open source development model is “release early, release often”. Involving volunteer users as testers is especially important taking into account modularity and massive concurrent development of open source software. A consequence of modularity and concurrent development is that open source components often have many flexible connections to other components. Moreover

55 open source software is traditionally ported to many hardware and software platforms. As a result each component can be potentially used in huge number of different configurations. Thus developers of open source software often are not able to test their software in all configurations. They test the software in some available configurations but testing the rest configurations is performed by volunteer testers.

Mature projects also exploit other quality assurance techniques such as unit, regression and system testing, etc. But generally such approach to quality assurance is not suitable for deployment of enterprise level systems. That is why specialized companies appear to provide some guarantees and support to end-users of open source software. They spend a lot of effort on quality assurance and compatibility testing of open source components for predefined set of software and hardware configurations. Examples of the companies are RedHat and Novell, which do this work for Linux operating system distributions RedHat Enterprise Linux and SUSE Linux Enterprise Server/Desktop correspondingly. These companies carefully check some cut of versions of open source software when they prepare major releases of their products. They have to make sure of not only quality of each component itself but also the set of versions they select for distribution does not contain implicit violations of restrictions on intercomponent interactions. And then they perform double code review of each change to source code of their enterprise level distributions before releasing security updates and service packs to enterprise customers.

Let us summarize the open source development model discussion. Open source changes rapidly and continuously. It makes happy end-users but it brings a lot of headache from the quality assurance point of view. The open source development model allows to detect many bugs but at the same time difficult-to-find bugs still take place. Essential part of the bugs is consequences of implicit violations of restrictions on interactions between several components coming from concurrent development of the components. Thus automation of detection of such violations is highly appreciated.

3 How Formal Methods Can Help?

How formal methods can help with this problem? Someone can imagine an ideal solution as follows:

1. An interface between components is described in a formal way, for example, using contract specifications (preconditions and postconditions).

2. Tools are developed to automatically verify compliance of source code to restrictions on interactions with an environment.

Unfortunately development of such tools is not feasible in the near future, so it required to find more realistic approaches.

We consider simplifications of the ideal solution by two directions. The first variant is also to describe the interface in a formal way but use run-time verification instead of formal verification. That is to check the formalized restriction in run time


56 Alexey Khoroshilov and Vadim Mutilin during real work of the components under test. The second variant is to use formal models of the most frequently encountered violations instead of formal specification of the interface as a whole and to develop a tool to statically check source code against these violations. Static analysis in restricted form is much simpler and there is a hope that the corresponding tools can be developed.

The drawback of the first variant is that run-time verification can detect violations that happen during testing only. That is, the problem of diversity of configurations remains unresolved. The advantage of the approach is that it allows identifying violation immediately it happens, whereas during testing without run-time verification a violation can become apparent in unexpected way and much later or even does not become apparent at all.

The advantages of the second variant are as follows: - it can detect bugs in many configurations simultaneously; - it can detect bugs without using hardware required to execute the code; - it even can detect the bugs requiring several rare events to happen

simultaneously to become apparent. The drawback of the approach is that it requires a separate model for each kind

of violations instead of using universal contract specification. At the same time development of a set of simple models requires much less efforts than development of a complex one.

To solve the problem discussed, that is, to automate detection of bugs related to violations of implicit restrictions on intercomponent interactions in open source projects the second approach seems for us to be more perspective. In the next section we consider our project aimed to implement this approach to automate detection of violations of restrictions on interactions between core of Linux operating system kernel and its device drivers. The first approach is also interesting but we believe it is more appropriate in the context of testing of applications conformance to standards requirements. We are going to investigate this approach in the scope of the LSB infrastructure program for testing applications against LSB [7].

4. Linux Driver Verification

One of the striking examples of open source software is Linux kernel. Typical difficulties of open source software development model we discussed above emerge in full measure here. The kernel is constantly and continuously updated. Linux Foundation [8] reports that from the 2.6.11 to the 2.6.24 kernel release (a total of 1140 days) there were, on average, 2.83 patches applied to the kernel tree per hour. It comes to an impressive 3,621 lines added, 1,550 lines removed, and 1,425 lines changed every day for the past 2 1/2 years. That rate of change is larger than any other public software project of any size.

There are also difficulties with modification approval in kernel development. Along with the main repository containing the official version there are several alternative repositories.

57

Although originally developed for 32-bit x86-based PCs (386 or higher), today Linux also runs on (at least) the Alpha AXP, Sun SPARC, Motorola 68000, PowerPC, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, AMD x86-64, AXIS CRIS, Renesas M32R, Atmel AVR32, Renesas H8/300, NEC V850, Tensilica Xtensa, and Analog Devices Blackfin architectures in both 32- and 64-bit variants for many of them [9]. These more than eighteen architectures cause difficulties in development because we need to be sure that kernel works properly on every supported architecture. To a large extent quality assurance becomes a headache of users, because such a vast variety of hardware configurations is impossible to gather together on developers’ site.

The errors in the kernel code have far reaching implications and tend to fail many other elements of computer system. These errors may result in fatal consequences: damage of the objects under control of computer, material loses, data leakage. The empirical data indicates [10,11] that bugs in kernel-space device drivers cause 85% system crashes. This results from several factors. Firstly, driver code constitutes the biggest part (up to 70%) of the operating system code. Secondly, drivers often are developed by suppliers of corresponding devices who are not so familiar with kernel peculiarities as kernel developers.

In contrast to testing which dynamically checks driver specific requirements, our approach is to statically check common rules that represent the most frequently encountered violations of restrictions on interactions between core of Linux operating system kernel and its device drivers. The common rules are the first part of a verification model. The second part of the verification model is model implementations of some part of Linux kernel API used by drivers for interaction with the core of the Linux kernel. The verification model is combined with source code of a driver under test and then it is passed to a verification tool. As a verification tool we have selected open source tool BLAST [12, 13, 14], which implements counter-example guided abstraction refinement (CEGAR) [15] for programs written in C programming language. As an input, BLAST takes a program written in C and containing calls to assert function. This function has one Boolean parameter. If there is an execution path where the assert function is called with false, the input program is considered as incorrect, otherwise it is considered as correct.

Drivers are kernel modules containing declarations of initialization and exit functions. Typically, an initialization function registers drivers’ event handler functions in the kernel. Driver is a reactive program by nature, i.e. operating system calls event handlers in unpredictable order. Since BLAST is aimed to verify sequential programs we developed a special toolset which translates source code of a driver into a sequential program modeling reactive behaviour of the source driver using especial nondeterministic operator supported by BLAST. The toolset generates usual entry point main() containing calls to initialization, exit functions and event handlers registered by the driver.

The translated code is combined with verification model and is passed to BLAST for verification. There are three possible results to be get from BLAST: system is safe, system is unsafe, cannot prove. The first verdict means that BLAST verifies


58 Alexey Khoroshilov and Vadim Mutilin that the driver does not violate the restriction formalized in the rule. The second verdict means that BLAST detects an execution path where the assert function is called with false and in this case it additionally generates error trace leading to this call. If the third verdict occurs, it means that BLAST can say nothing regarding to the program given.

Let us consider, for example, a driver for Mylex DAC960 RAID Controller which can be found in the kernel source tree (/linux/drivers/block/DAC960.c). Its development has typical characteristics of open source software development.

Drivers are continuously improved. For each new device we should modify existing drivers or write new ones. In the kernel version 2.3 this driver worked with one set of hardware, but starting with version 2.4 it began to work with another set of hardware that required sufficient rewriting. In version 2.5 one more important modification appeared. The driver began to use pci_pool structures. All made modifications should satisfy common rules, which are restrictions on interactions between the drivers and the kernel. So, one of the rules in our collection (ID0029) requires that system call pci_pool_alloc appeared only after successful call to pci_pool_create. This restriction should be satisfied for any code which uses functions working with pci_pool, among them the code of DAC960 driver. Toolset considered in the paper allows checking this rule automatically.

If drivers are developed in proprietary way developers often are not taking part in the kernel development. Every time the kernel is updated they need to make sure that drivers correctly use the kernel interfaces. A part of kernel functions become deprecated, another part is replaced by optimized ones recommended for using by driver developers. For example, in kernel 2.6 it is recommended to use special macro definitions instead of reserved function names for declaration of initialization and exit functions. Another example, the specialized functions sleep_on()/wake_up() were superseded by new mechanism based on wait queue. These recommendations are written in the form of rules that are checked automatically.

Let us consider the rule ID0029 in more details. In order to verify this rule it is necessary to make sure that every time pci_pool_alloc is called, it takes pointer to pci_pool structure returned by successful call to pci_pool_create. We will replace system calls pci_pool_create and pci_pool_alloc by our model implementations. The Fig. 1 shows model implementations of these functions.

Created pools are stored in the array the_pools and their states are stored in the array pool_states. States can be as follows: 0 – not exists, 1 – created, 2 – allocated, 3 – freed, 4 – destroyed. Function pci_pool_create tries to allocate memory for a new pool and in case of success it saves the pointer to allocated memory in the array the_pools setting its state to 1 (pool created). In function pci_pool_alloc it is checked that the state saved in pool_states equals to 1. Hence, we guarantee that the pool was created by successful call to pci_pool_create. Note that for formalization we use arrays of limited size and moreover we use constant indices for access to elements of the arrays instead of variables. These decisions were made because we encounter a number of BLAST restrictions in performing pointer alias analysis.

59

struct pci_pool * the_pools[1];

int pool_states[2];

struct pci_pool *pci_pool_create( const char *name, struct device *dev,

size_t size, size_t align, size_t allocation )

{

void *new_pool = kmalloc(sizeof(int));

if(!new_pool) return NULL;

if(the_pools[0]==NULL) {

assert(pool_states[0] == 0) || pool_states[0] == 4);

the_pools[0]=new_pool;

pool_states[0]=1;

} else if(the_pools[1]==NULL) {

assert(pool_states[1] == 0) || pool_states[1] == 4);

the_pools[1]=new_pool;

pool_states[1]=1;

}

return new_pool;

}

void *pci_pool_alloc( struct pci_pool *pool, gfp_t mem_flags,

pci_addr_t *handle )

{

void *the_qtd = kmalloc(sizeof(int));

if(!the_qtd) return NULL;

if (the_pools[0]==pool) {

assert(pool_states[0] == 1 || pool_states[0] == 2);

pool_states[0]=2;

} else if(the_pools[1]==pool) {

assert(pool_states[1] == 1 || pool_states[1] == 2);

pool_states[1]=2;

} else {

assert(0);

}

return the_qtd;

}

Fig. 1. Model implementations of pci_pool_create and pci_pool_alloc kernel API functions

Let us consider our verification process applied to the example of DAC960 driver. As the result of driver instrumentation with our toolset the main function is generated containing calls to initialization function DAC960_init_module, exit


60 Alexey Khoroshilov and Vadim Mutilin function DAC960_cleanup_module and event handlers DAC960_Probe, DAC960_Remove. Then the code is merged with verification model including model implementations of pci_pool_create, pci_pool_alloc, pci_pool_free, pci_pool_destroy. The result is given as an input to BLAST. DAC960 driver taken from kernel version 2.6.23.1 successfully passes verification with the verdict "system is safe". In order to demonstrate which errors can be found, we inject an error in the driver. We take function DAC960_CreateAuxiliaryStructures shown on the Fig. 2 which is called from DAC960_Probe. Suppose that after an attempt to create ScatterGatherPool there is no check for null pointer (the lines commented), then the subsequent call to pci_pool_alloc may fail if null pointer ScatterGatherPool is given to it. BLAST successfully finds the error and generates the trace shown on the Fig. 3. Note that in case of regular testing and runtime verification it is hard to detect the error because it requires reproducing a situation when pci_pool_create fails that rarely happens in practice and, moreover, the error occurs only on the one controller type.

if (Controller->FirmwareType == DAC960_V1_Controller)

{

…

ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",

Controller->PCIDevice,

DAC960_V1_ScatterGatherLimit *

sizeof(DAC960_V1_ScatterGatherSegment_T),

sizeof(DAC960_V1_ScatterGatherSegment_T),

0);

// if (ScatterGatherPool == NULL)

// return DAC960_Failure(Controller,

// "AUXILIARY STRUCTURE CREATION (SG)");

…

}

else

{

…

}

…

ScatterGatherCPU = pci_pool_alloc(ScatterGatherPool, GFP_ATOMIC,

&ScatterGatherDMA); Fig. 2. Snippets of source code of driver for Mylex DAC960 RAID Controller

Our goal is to identify a set of verification rules as complete as possible covering all known problems in device drivers. By now we have collected 71 rules. There are rules specific for particular type of devices (such as char, block devices, etc.) and there are rules applicable for all drivers. Among the latter rules we identify the following general groups:

61

- rules applicable for any C program (e.g. array access by negative indices); - rules on using locking primitives (e.g. double spin lock/unlock); - rules on resource allocation (e.g. rule ID0029 described above); - rules on using kernel API in atomic context (e.g. non-preemptible memory

allocation). 219: FunctionCall(dma_pool_create())

72: FunctionCall(malloc())

43: Block(__retres@malloc = 0;)

74: Block(__retres@dma_pool_create = 0;)

238: FunctionCall(dma_pool_alloc())

95: FunctionCall(malloc())

41: Block(__retres@malloc = tmp___0@malloc;)

96: Pred(the_qtd@dma_pool_alloc != 0)

98: Pred(the_pools[ 0 ] == pool@dma_pool_alloc)

100: Pred(pool_states[ 0 ] != 1)




100: Block(tmp___0@dma_pool_alloc = 0;)

100: FunctionCall(__assert_fail()) Fig. 3. Error trace generated by BLAST for an injected bug in DAC960 driver

Another classification of rules is based on kind of the property under verification: - safety rules; - liveness rules; - syntactic rules. Formal methods implemented in BLAST tool are intended for verification of

arbitrary safety properties which are the most numerous (54 rules). More than a half of them (30 rules) can be successfully formalized and our toolset supports preparing drivers for the verification with BLAST. Unfortunately, there are rules that cannot be verified now. Firstly, it is the rules involving access to driver variables. For example, the rules that requires checking whether pointer variable is null. Secondly, it is the rules imposing restrictions on using attributes from C language extension supported by gcc compiler. For example, the rules that checks the presence of attribute __user for function parameters.

BLAST cannot deal with liveness rules at all. Syntactic rules require checking of deprecated types, fields, functions, and gcc extensions. BLAST is not well suited for the analysis of such rules too.

In our future work we plan to improve the tools to enable checking of all safety rules collected and to develop advanced syntactic analyzer for verification of syntactic rules.


62 Alexey Khoroshilov and Vadim Mutilin 5 Summary

In the paper we have proposed an approach to automate detection of bugs related to violations of implicit restrictions on intercomponent interactions in open source projects. The first application of the approach is the Linux driver verification project, where we are working on detection bugs consisting in invalid usage of Linux kernel API in Linux device drivers. If we succeed in identification, formalization and verification of rules representing the most frequently encountered bugs in device drivers of a specific version of the kernel for a specific architecture we will enable rather simple drivers certification process. This process will not require presence of any specialized hardware and it will provide at least some minimal level of confidence in compatibility of a driver to the given kernel. It is worth to mention that similar programme is in progress in Microsoft Corporation regarding to Windows device drivers [16, 17, 18].

Linux device drivers are very good area to evaluate the proposed approach because the source code of drivers is rather simple, it does not contain floating point arithmetic and too complicated data structures. Hopefully modern verification tools and techniques are able to solve such verification problems in most cases. In the case of success the tools developed will provide a good base for further expansion of the approach for verification of other open source intercomponent interfaces.

References

1. Gillen A, Stergiades E, Waldman B (2008) The Role of Linux Servers and Commercial Workloads. http://www.linux-foundation.org/publications/IDC_Workloads.pdf

2. Gartner Report (2008) The State of Open Source - 2008. http://www.gartner.com/; report G00156659.

3. Anthony Senyard, Martin Michlmayr, (2004) How to Have a Successful Free Software Project, pp. 84-91, 11th Asia-Pacific Software Engineering Conference (APSEC'04).

4. MacCormack A, Rusnak J, and Baldwin C (2004) Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code, in Harvard Business School Working Paper. Boston, MA 02163.

5. Raymond E, (2001) The Cathedral and the Bazaar. O'ReillyPublishing Company, First Edition.

6. Glass R. (2003) Facts and Fallacies of Software Engineering. Addison-Wesley, ISBN 0321117425.

7. http://www.linux-foundation.org/en/LSB. 8. Kroah-Hartman G, Corbet J, McPherson A (2008) Linux Kernel

Development. http://www.linux-foundation.org/publications/linuxkerneldevelopment.php.

9. http://www.kernel.org.

63

10. A. Chou et al. (2001) An Empirical Study of Operating System Errors, In Proc. of the 18-th ACM Symp. Operating System Principles, ACM Press.

11. Swift M, Bershad B, Levy H. (2003) Improving the reliability of commodity operating systems. In SOSP’03: Symposium on Operating System Principles.

12. Beyer D, Henzinger T, Theoduloz G. (2006) Lazy Shape Analysis, In Proc. of the 18-th Int. Conf. on Computer Aided Verification, 2006, LNCS, v. 4144, p. 532–546.

13. Beyer D, Henzinger T, Theoduloz G. (2006) Configurable Software Verification: Concretizing the Convergence of Model Checking and Program Analysis, In Proc. the 19-th Int. Conf. on Computer Aided Verification, 2006, LNCS, v. 4590, p. 504–518.

14. Beyer D, Henzinger T, Jhala R, Majumdar R. (2007) The Software Model Checker Blast: Applications to Software Engineering, Int. Journal on Software Tools for Technology Transfer, v. 9, N 5–6, 2007, p. 505–525.

15. Clarke E, Grumberg O, Jha S, Lu Y, Veith H. (2000) Counterexampleguided abstraction refinement. In Proc. of the 18-th Int. Conf. on Computer Aided Verification, 2000, LNCS, v. 1855.

16. Ball T, Podelski A, Rajamani S. (2001) Boolean and Cartesian Abstraction for Model Checking C Programs, 2001, LNCS, v. 2031, p. 268–280.

17. Ball T, Rajamani S. (2002) The SLAM project: debugging system software via static analysis, In Proc. of the 29th ACM SIGPLAN-SIGACT Symp. on Principles of Programming Languages, 2002, p. 1–3.

18. Ball T, Bounimova E, Cook B, Lichtenberg J, McGarvey C, Ondrusek B, Rajamani S, Ustuner A. (2006) Thorough static analysis of device drivers. In Proc. of EuroSys’06: European Systems Conference, 2006.


Extracting and verifying coordination models from source

code

Nuno F. Rodrigues1 and Luıs S. Barbosa1

CCTC, Universidade do Minho 4710-057 Braga, Portugal{nfr, lsb}@di.uminho.pt

Summary. Current software development relies increasingly on non-trivial coordination logic for com-bining autonomous services often running on different platforms. As a rule, however, in typical non-trivialsoftware systems, such a coordination layer is strongly weaved within the application at source code level.Therefore, its precise identification becomes a major methodological (and technical) problem which cannotbe overestimated along any program understanding or refactoring process.

Open access to source code, as granted in OSS certification, provides an opportunity for the devel-opment of methods and technologies to extract, from source code, the relevant coordination information.This paper is a step in this direction, combining a number of program analysis techniques to automaticallyrecover coordination information from legacy code. Such information is then expressed as a model in Orc,a general purpose orchestration language.

1 Introduction

The increasing relevance and exponential growth of software systems, both in size and quantity,is leading to an equally growing amount of legacy code that has to be maintained, improved,replaced, adapted and accessed for quality every day. Such is the scenario for the emergence ofexpressions like program understanding, reverse engineering and model extraction, referring to abroad range of techniques to extract from legacy code specific and rigorous knowledge, representit in malleable representations, proceed to their analysis, classification and reconstruction.

Such techniques find in the whole process of Open-Source Software (OSS) certification a promis-ing application area, given that

• OSS applications often emerge by composition of multi-source, heterogeneous and previouslyunrelated pieces of code, which makes architectural recovery processes both useful and chal-lenging;

• full access to source code enables the effective application of approaches and tools entirelybased in code analysis.

Several approaches have been proposed for reverse architectural analysis. For example, class

diagram generators which extract class diagrams from object oriented source code, module diagram

generators that construct box-line diagrams from system’s modules, packages or namespaces, uses

diagram generators which reflect the import dependencies of the system and call diagram genera-tors which expose the direct calls between system parts. However, none of these techniques/toolsmake it possible to answer a critical question about the dynamics of a system: how do system’s

components interact, internally and with external services, and orchestrate their behaviours to

achieve common, complex goals? From a call diagram, for example, one may identify which partsof a system (and, sometimes, even what external systems) are called during the execution of aparticular procedure. No answers are provided, however, to questions like: Will the system try tocommunicate indefinitely if an external resource is unavailable? If a particular process is down,will it cause the entire system to halt? Can the system enter in a deadlock situation? and what isthe sequence of actions for such a deadlock to take place?

65 Nuno F. Rodrigues and Luıs S. Barbosa

Actually, recovering a coordination model is a complex process. This complexity arises fromthe need to deal with multiple activities and multiple participants which in turn are influencedby multiple constrains, such as exceptions, interrupts and failures. On the other hand, the evergrowing number of systems relying on non-trivial coordination logic for combining autonomousservices, entails the need for methods and tools to support such a process.

Identify, extract and record the coordination layer of running applications is becoming moreand more relevant as an increasing number of software systems rely on non-trivial coordinationlogic for combining autonomous services, typically running on different platforms and owned bydifferent organisations.

This paper is a step towards addressing such a problem. Its main contribution is a techniquewhich adapts typical program analysis algorithms, namely slicing [22], to recover coordination in-formation from legacy code. This is based on a notion of coordination dependence graph proposedhere as a specialisation of standard program dependence graphs [5] used in classical program anal-ysis. The recovered coordination patterns are automatically expressed in Orc, a general purposeorchestration language developed by J. Misra and W. Cook [15]. Orc scripts can be animated tosimulate such patterns and study alternative coordination policies.

In an OSS development context, the method discussed in the paper can be used both

• to identify, extract and record the coordination layer of running OSS applications;• to validate the coordination strategies implemented in a OSS program (i.e., a program to which

access to code is granted) against a previous specification of its requirements.

The latter use is illustrated through a small, academic example in section 5.Finally, it should be stressed that the technique discussed in this paper is generic in the sense

that it does not depend upon the programming language or platform in which the original systemwas developed. In fact it can be implemented to target any language with basic communicationsand multi-threading capabilities. In the sequel this is illustrated with the C♯ language in order tokeep the presentation self-contained. However, a support tool [21] was developed, as a “proof-of-concept” for this technique, which analyses any piece of CIL (Common Intermediate Language)source code.

The paper is organised as follows. Section 2 provides the necessary background with a briefreview of both slicing techniques and the Orc coordination language. Section 3.1 introduces a newgraph based program representation suitable for representing concurrent object oriented programsand its tuning to what we call a coordination dependence graph. Then, in section 4, the generationof an Orc script from the system’s graph representations is discussed in details. Section 5 showsthe “method-in-action” through a small example in which a previous specification is checkedagainst the coordination model recovered from the implementation. Finally, section 6 concludesand identifies a number of topics for future work.

2 Background

2.1 Program slicing and graph-based representations

Introduced by Weiser [25, 23, 24] in the late 1970s, program slicing is a family of techniques for iso-lating parts of a program which depend on or are depended upon a specific computational entityreferred to as the slicing criterion. In Weiser’s view, program slicing is an abstraction exercisethat every programmer has gone through, aware of it or not, every time he undertakes source codeanalysis. Weiser’s original definition has been since then re-worked and expanded several times,leading to the emergence of different methods for defining and computing program slices [3, 22].

Weiser’s approach corresponds to what would now be classified as an executable, backward,static slicing method. A dual concept is that of forward slicing introduced by Horwitz et al. [7].In forward slicing one is interested on what depends on or is affected by the entity selected as theslicing criterion. Note that combining the two methods also gives interesting results. In particular

Extracting and verifying coordination models from source code 66

the union of a backward to a forward slice for the same criterion n provides a sort of a selectivewindow over the code highlighting the region relevant for entity n.

Another duality pops up between static and dynamic slicing. In the first case only staticprogram information is used, while the second one also considers input values [9, 10] leadingfrequently, due to the extra information used, to smaller and easier to analyse slices, althoughwith a restricted validity.

In this paper we are interested in a static, backward, inter-procedural slicing algorithm whichcan isolate the sub-program that potentially affects a particular statement.

Most slicing techniques are based on different Graph-based representations of the programsbeing sliced. In particular, the so-called System Dependence Graph (SDG)[7] stands as the baserepresentation for most inter-procedural slicing techniques. The coordination analysis algorithmproposed in this paper is also based on SDG’s.

2.2 Program coordination in Orc

Purpose and syntax.

Many traditional concurrency problems, like business workflows, resource sharing and compositeweb services built from service level agreements, can be regarded as orchestrations of third partyresources. Orc [15] is a simple, yet powerful task orchestration language. Unlike other concurrencymodels, Orc regards the coordination of different activities and participants in a centralisedmanner. Thus, in Orc, external services never take the initiative of beginning communication,there is always a centralised entity that controls the calling of foreign operations.

The language builds upon few simple basic constructs that provide succinct and understandablecoordination specifications of systems. In summary, the language provides a platform for simplespecification of third-party resources invocations with a specific goal to accomplish, while managingconcurrency, failure, time-outs, priorities and other constrains.

A number of formal semantics [8, 1] have been purposed for Orc which provide a solid theo-retical background upon which one can base equivalence and program transformation.

In Orc, third party services are abstracted as sites which can receive calls from an Orc

specification (orchestration). Included in this definition of sites are user interaction activities andthird party data manipulation. An orchestration consists of a set of auxiliary definitions and amain goal expression upon which the specification evaluation begins.

e, f, g, h ∈ Expression ∶∶= M(p) ∥ E(p) ∥ f > x > g ∥ f ∣g ∥ f where x ∶∈ g ∥ x

p ∈ Actual ∶∶= x ∥ M ∥ c ∥ f

q ∈ Formal ∶∶= x ∥ M

Definition ∶∶= E(q) ≜ f

Fig. 1. Orc syntax

The syntax of the language is presented in figure 1, where definitions for Orc Expressions,Actual parameters p, Formal parameters q and Definitions are given.

An Orc expression can be composed by a site call M(p), an expression call E(p), a sequentialexecution of expressions f > x > g, a parallel execution of expressions f ∣g, an asymmetric parallelcomposition of expressions f where x ∶∈ g, or a variable x.

There are a few fundamental sites in Orc which are essential for effective programming of realworld orchestrations. These fundamental site along with its informal semantics are presented inTable 1.

Orc also provides means for creating dynamic orchestrations, i.e., orchestrations that are ableto create local sites at runtime. This feature is provided by special sites, called Factory Sites, whichreturn a local site when invoked. Table 2 describes some useful factory sites, taken from [4], thatwill be required ahead for capturing some coordination schemas.


let(x, y, ...) Returns argument values as a tuple.if(b) Returns a signal if b is true, and it does not respond if b is false.Signal Returns a signal. It is same as if(true)RTimer(t) Returns a signal after exactly t time units

Table 1. Fundamental sites

Site Operations Description

Buffer put, get The Buffer factory site returns a n− buffer local site with two operations,put and get. The put operation stores its argument value in the buffer andsends a signal after the storage. The get operation removes an item from thebuffer and returns it. In case the buffer is empty the get operation suspendsuntil a value is putted in the buffer.

Lock acquire,release

The Lock factory site returns a lock local site which provides two operations,acquire and release. When an expression invokes the acquire operation ona lock, that expression becomes its owner and subsequent calls to acquire

from other expressions will block. Once the lock owner expression releasesit, ownership of the lock will be given to one of the acquire operationwaiting expression, if any.

Table 2. Factory sites

Informal semantics.

A site in Orc is an independent entity with the capacity of publishing values to the callingexpressions. The evaluation of a site call holds indefinitely (possibly forever if the site neverpublishes a value) until the called site publishes a value. An expression call simply passes thecontrol from the current expression being evaluated to the called expression with the associatedparameters. A sequential execution of expressions f > x > g is executed by evaluating expressionf , binding the value published by f to x and then evaluating expression g which may containreferences to x. In case x isn’t used by g, the sequential expression may be written as f >> g.Parallel composition of expressions is carried out by the concurrent execution of the interveningexpressions. Finally, asymmetric parallel composition f where x ∶∈ g is evaluated by evaluatingf and g in parallel and evaluation of f holds whenever it depends on variable x and g has notpublished any value. Once g publishes a value, its evaluation is halted and the value produced isstored in x, enabling expression f evaluation to continue. For a formal semantics of the languagesee [8, 1]. Table 3 presents a number of typical Orc definitions upon which the Orc generationprocess of section 4 builds.

XOR(p, f, g) ≜ if(p) ≫ f ∣ if(¬p) ≫ g

IfSignal(p, f) ≜ if(p) ≫ f ∣ if(¬p)Loop(p, f) ≜ p > b > IfSignal(b, f ≫ Loop(p, f))Discr(f, g) ≜ Buffer > B > ((f ∣ g) > x > B.put(x) ∣ B.get)

Table 3. Some Orc definitions

The XOR definition takes as arguments a predicate expression p, and two orchestrations f andg. If p evaluates to true then orchestration f is executed, otherwise g is executed. Regard that, inspite of the parallel operator the definition only executes one of the expressions f and g and thatone of them is always executed.


The IfSignal definition receives a predicate and an orchestration and executes the orchestra-tion if the predicates evaluates to true. Again, notice that whether p evaluates to true or falsethe definition never blocks, it always publishes a value, thus permitting the calling orchestrationto proceed.

The Loop expression receives a predicate p and an orchestration f . This definition executes fcontinuously until predicate p evaluates to false. If predicate p evaluates to false the definitiondoesn’t block and returns a signal in order for the calling orchestration to proceed.

Definition Discr makes use of the factory site Buffer in order to capture the signal of the firstof its two parameter orchestrations to respond. Once one of the orchestrations returns a signal,the signal is forwarded to the calling orchestration, but leaving the other parameter orchestrationexecuting until it finishes.

3 Two graph representations for program analysis

3.1 Managed system dependence graph

The fundamental information structure underlying the coordination discovery method proposed inthis paper is a comprehensive dependence graph — the MSDG — recording the elementary entitiesand relationships that may be inferred from the code by suitable program analysis techniques.

A MSDG is an extension of a system dependence graph to cope with object-oriented features,as considered in [12, 13, 26]. Our own contribution was the introduction of new representationsfor a number of program constructs not addressed before, namely, partial classes and methods,delegates, events and lambda expressions. In the sequel a brief overview of the structure of aMSDG is made; the reader is, however, referred to [20] for a formal specification of a MSDG, aswell as for a detailed description of the techniques used in its construction.

A MSDG is defined over three types of nodes representing program entities: spatial nodes

(subdivided into classes Cls, interfaces Intf and name spaces Nsp), method nodes (carrying infor-mation on methods’ signature MSig, statements MSta and parameters MPar) and structural nodeswhich represent implicit control structures (for example, recursive references in a class or a forkof execution threads). Formally,

Node = SNode +MNode +TNode

SNode = Cls + Intf +Nsp

MNode = MSig +MSta +MPar

TNode = {△,▽, ○}

where + denotes set disjoint union. Nodes of type SNode contain just an identifier for the associatedprogram entity. Other nodes, however, exhibit further structure a MSta includes the statementcode (or a pointer to it) and a label to discriminate among the possible types of statements in amethod, i.e.,

MSta = SType × SCode

Stype = {mcall, cond,wloop, assgn,⋯}

where, for example, mcall stands for any statement containing a call to a method and cond fora conditional expression. Similarly, a MSig node, which in the graph acts as the method entrypoint node, records information on both the method identifier and its signature, i.e., MSig =Id × Sig. Method parameters are handled through special nodes, of type MPar, representing input(respectively, output) actual and formal parameters in a method call or declaration. Formally,

MPar = PaIn + PaOut + PfIn + PfOut

Finally, the structural nodes TNode were introduced to cope with concurrency (case of △ and▽) and to represent recursively defined classes (case of ○). A brief explanation is in order. A △


node captures the effect of a spawning thread: it links an incoming control flow edge, from thevertex that fired the fork, and two outgoing edges, one for the new execution flow and anotherfor the initial one. Dually, a thread join is represented by a ▽ node with two incoming edges andan outgoing one to the singular resumed thread. A ○ node represents a recursively defined class,what seems a better alternative than expanding the object tree to a certain, but fix, depth, used,for example, in [13].

There are, of course, several types of dependencies represented as edges in a MSDG. A edge isa tuple of type

Edge = Node ×DepType × (Inf + 1) ×Node

where DepType is the relationship type and the third component represents, optionally, additionalinformation associated to it. Let us briefly review the main types of dependency relationships.Data dependencies, of type dd, connect statement nodes with common variables. Formally,

⟨v,dd, x, v′⟩ ∈ Edge⇔ definedIn(x, v) ∧ usedIn(x, v′)

Typical dependencies between statement nodes are control flow, cf, and control, ct, the latterconnecting guarded statements (e.g. loops or conditionals) or method calls to their possible con-tinuations and method signature nodes (which represent the entry-points on a method invocation)to each of the statement nodes within the method which is not under the control of anotherstatement. Formally, these conditions add the following assertions to the invariant of type Edge:

⟨v, ct, g, v′⟩ ∈ Edge⇐ v ∈ {MSta(t,−)∣ t ∈ {mcall, cond,wloop}}

⟨v, ct,−, v′⟩ ∈ Edge⇐ v ∈MSig ∧ v′ ∈MSta

where g is either undefined or the boolean result of evaluating the statement guard.A method call, on the other hand, is represented by mc dependency from the calling statement

and the method signature node. Formally,

⟨v,mc, vis, v′⟩ ∈ Edge⇔ v ∈MSta(mcall,−) ∧ v ∈MSig

where vis stand for a visibility modifier in set {private,public,protected, internal}. Specific depen-dencies are also established between nodes representing formal and actual parameters. Moreover,all of the former are connected to the corresponding method signature node, whereas actual param-eter nodes are connected to the method call node via control edges. Finally, any data dependencebetween formal parameters nodes is mirrored in the corresponding actual parameters. Summingup, these adds the following assertions to the MSDG invariant:

⟨v,pi,−, v′⟩ ∈ Edge⇔ v ∈ PaIn ∧ v ∈ PfIn

⟨v,po,−, v′⟩ ∈ Edge⇔ v ∈ PaOut ∧ v ∈ PfOut

⟨v, ct,−, v′⟩ ∈ Edge⇐ v ∈MSig ∧ v ∈ (PaIn ∪ PaOut)

⟨v, ct,−, v′⟩ ∈ Edge⇐ v ∈MSta(mcall,−) ∧ v ∈ (PfIn ∪ PfOut)

⟨v,dd,−, v′⟩ ∈ Edge⇐ v ∈ PaIn ∧ v′ ∈ PaOut ∧ ∃⟨u,dd,−,u′⟩ . (u ∈ PfIn ∧ u′ ∈ PfOut)

Class inheritance and the fact the a class owns a particular method is recorded as follows

⟨v, ci,−, v′⟩ ∈ Edge⇔ v, v

′ ∈ Cls ∧ v ≠ v

⟨v, cl, vis, v′⟩ ∈ Edge⇔ v ∈ Cls ∧ v′ ∈MSig

and, similarly, for interface and namespace nodes.Other program entities and properties typically found in modern programming languages are

also captured in a MSDG. They include, namely, properties (a special program construct in C

♯)and other .Net-based languages, intended to encapsulate access to class variables. But also partial

classes and partial methods, the latter entailing the need for a mc dependence edge between the


declaration of the partial method and its implementation, as well as delegates, events and λ-

expressions. A delegate is a sort of a function whose values are objects, thus possibly defining classmember types from the subscribed side, i.e., the class with the delegate definition that invoke thesubscribed method, a method node is added to represent the delegate type, as well as parameternodes for its arguments and results. Every call to the delegate inside the subscribed class isrepresented by a method call edge to the MSig node introduced by the delegate type. This actslike a proxy dispatching its calls to objects and methods which subscribed the delegate. In whatconcerns to graph representation, the difference between delegates and events is that the lattercan be subscribed by more than one method, whilst delegate subscriptions override each other.Therefore, their representation in a MSDG is similar to that of delegates, but for the possibility ofco-existence of more than one mc edge between the subscribed and the actual method to be calledin the subscriber. A similar approach is taken for the representation of λ-expressions, which in C♯

are stateful and behave as anonymous methods (see [20] for further details).

3.2 The coordination dependence graph

The second stage in the discovery process is the construction of a coordination dependence graph(CDG), which basically prunes the MSDG of all information not directly relevant for the recon-struction of the application coordination layer. This stage is guided by a specification of a set ofrules specifying the interaction primitives used in the source code, which are actually the buildingblocks of any coordination scheme. Such rules are specified as

CRule = RExp × (CType × CDisc × CRole)

CType = {webservice, rmi, remoting,⋯}

CDisc = {sync, async}

CRole = {provider, consumer}

where RExp is a regular expressions, CType is the type of communication primitive types (exten-sible to other classes of communication primitives), CDisc is the calling mode (either synchronousor asynchronous) and, finally, CRole characterises the code fragment role wrt the direction ofcommunication. In the C♯, for example, the identification of invocations to web services can becaptured by the following rule, which identifies the primitive synchronous framework methodSoapHttpClientProtocol.Invoke usually used to call web services:

R = ("SoapHttpClientProtocol.Invoke(*);", (webservice, sync, consumer))

Given a set of rules, the CDG calculation, starts by testing all the MSDG vertices against theregular expressions in the rules. If a node statement matches the regular expression of a rule, it islabelled with the information in the rule’s second component.

On completion of this labelling stage, the method proceeds to abstract away the parts of thegraph which do not take part in the coordination layer. This is a major abstraction process ac-complished by removing all non-labelled nodes, but for the ones verifying the following conditions:

1. method call nodes (i.e., nodes n such that n ∈MSta with STypen = mcall) for which there is acontrol flow path (i.e., a chain of cf dependency edges) to a labelled node.

2. vertices in the union of the backward slice of the program with respect to each one of thelabelled nodes.

Note that the first condition ensures that the relevant procedure call nesting structure is kept.This information will be useful to nest, in a similar way, the generated code on completion ofthe discovery process. The second condition keeps all the statements in the program that maypotentially affect a previously labelled node. This includes, namely, MSta nodes whose statementscontain predicates (e,g., loops or conditionals) which may affect the parameters for execution ofthe communication primitives and, therefore, play a role in the coordination layer.


This stage requires a slicing procedure over the MSDG, for which we adopt a backward slicingalgorithm similar to the one presented in [7]. It consists of two phases. The first phase marksthe visited nodes by traversing the MSDG backwards, starting on the node matching the slicingcriterion, and following ct, mc, pi, and dd labelled edges. The second phase consists of traversingthe whole graph backwards, starting on every node marked on phase 1 and following ct, po, anddd labelled edges. By the end of phase 2, the program represented by the set of all marked nodesconstitutes the slice with respect to the initial slicing criterion.

Except for cf labelled edges, every other edge from the original MSDG with a removed nodeas source or target, is also removed from the final graph. The same is done for any cf labellededge containing a pruned node as a source or a sink. On the other hand, new edges are introducedto represent by direct control flow dependencies which were, previously to the removal operation,chains of such dependencies in the original MSDG. This ensures that future traversals of this graphare performed with the correct control order of statements.

4 Generating Orc scripts

The final phase in the method proposed in this paper is the generation of an Orc specificationfrom the CDG previously built. This abstracts the entire behaviour of the system in a rigorousspecification.

We believe that a coordination specification that is closer in structure to the original system ismore understandable and, moreover, easier to confront with the original system. Therefore, in orderto keep the original system’s procedure calls nesting structure, an Orc definition is generated foreach procedure in the CDG. The calling structure involving these procedures and recorded in thegraph is also kept. Actually, it is this structure preservation goal that justifies the first exceptionin the pruning process mentioned in the previous section.

Note, however, the process does not generate an Orc definition for every procedure in thesystem, since during the construction of the CDG most procedures (more specifically, the ones notcontributing to the coordination layer) were dropped. Also notice, it is quite simple to transform thenested Orc specification into a flat one, whenever this simplifies reasoning about the coordinationspecification.

The Orc generation process for a procedure is based on the program captured by the proceduresub-graph of the entire system CDG. The construction of the program represented by a CDG isquite straightforward and basically amounts to collecting the statements of the visited vertices byfollowing the control flow edges.

To keep the presentation as succinct as possible, one formalises the Orc generation processover the subset1 of C♯ presented in figure 2. The representation of CDG instances in this languageis a straightforward process, since of the constructs defined by the language are common to mostpopular language and the ones less so, like LOCALCALL and ASYNCCALL, are easily extracted fromthe vertices labelling information of the CDG.

The language is quite self explanatory. We consider that a local procedure call is as a syn-chronous call to a resource in the same machine not involving any communication primitive.Every asynchronous procedure call must be performed as if being made to an external resource, inwhich case it must specify the resource site uniquely (internal asynchronous procedure calls maybe performed using the ASYNCCALL construct with localhost as resource site). The ≺ ≻ bracketsused in the language definition stand for optional expressions.

As it happens in the complete C

♯ language, this subset also provides two possibilities forperforming asynchronous calls. One simply launches the procedure call in a separate thread andcontinues execution of the rest of the program. The other executes an expression when and ifthe asynchronous call returns. The LOCK statement behaves as expected i.e., it gives a variableaccess to a specific statement block execution in a single thread or process. All the remaining

1 Actually, we address all the relevant control flow, concurrency, and communication primitives of thelanguage.


z ∈ Valuesx,x1, xn ∈ Variables

s ∈ Sitese, e1,2n ∈ Expressions

st, st1, st2 ∈ Statements ∶∶= z

∣ x

∣ x = e

∣ st1 ; st2

∣ LOCK (x) {st}∣ LOCALCALL f(x)

∣ SYNCCALL s f(x)

∣ ASYNCCALL s f(x) ≺ {st} ≻∣ IF p THEN {st1} ≺ ELSE {st2} ≻∣ WHILE p DO {st}

f1, fn ∈ Procedures ∶∶= f(x){st}c1, cn ∈ Classes ∶∶= c {x1 = e1 ... xn = en f1 ... fn}

ns1, nsn ∈ Namespaces ∶∶= ns {c1 ... cn}

Fig. 2. Modified C♯ language subset

details concerning the syntax and the semantics of the language are borrowed from the completeC

♯ language.Although the input of the Orc generation process is the CDG of the program, for practical

reasons one has opted to formalise the functions that specify this process over the subset of theC

♯ language.The Orc generation is composed of two distinct phases. The first one is performed by function

ψ which identifies all the variables in the language for which an access control may be required, andsets up an environment for controlling the access to such variables. Basically, function ψ introducesa Lock site for each variable in a LOCK statement, while keeping track of all visited variables foravoiding site duplication. In the following definitions one uses product projections π1 ∶ A ×B → A

and π2 ∶ A×B → B as well as their dual co-product embeddings ι1 ∶ A→ A+B and ι2 ∶ B → A+B.

ψ (LOCK (x) {st}, V ) ≡⎧⎪⎪⎨⎪⎪⎩

(ι2(Lock > xLock > Signal),{x} ∪ V ) if x ∉ V ,

(ι1(), V ) otherwise

ψ (ASYNCCALL s f(x) {st}, V ) ≡(ψ1 st, ψ2 st ∪ V )

ψ (IF p THEN {st}, V ) ≡(ψ1 st, ψ2 st ∪ V )

ψ (IF p THEN {st1} ELSE {st2}, V ) ≡

⎧⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎩

(ψ1 st1, ψ2 st1 ∪ V ) if ψ1 st1 ≠ ι1() ∧ ψ1 st2 = ι1(),

(ψ1 st2, ψ2 st2 ∪ V ) if ψ1 st1 = ι1() ∧ ψ1 st2 ≠ ι1(),

(ι2(ψ′1st1 ≫ ψ

′1st2),

ψ1 st1 ∪ ψ1 st2 ∪ V ) if ψ1 st1 ≠ ι1() ∧ ψ1 st2 ≠ ι1(),

(ι1(), V ) otherwise

ψ (WHILE p DO {st}, V ) ≡(ψ1 st, ψ2 st ∪ V )

ψ (st1 ; st2, V ) ≡((ι2(ψ′1st1 ≫ ψ

′1st2), ψ1 st1 ∪ ψ1 st2 ∪ V )

ψ (st, V ) ≡(ι1(), V )

where

ψ1 = π1 . ψ

ψ2 = π2 . ψ

ρ2(ι2 x) = x

ψ

′1= ρ2 . π2 . ψ


The second phase of this process is performed by function ϕ which, for every procedure body,generates the corresponding Orc definition. Note that function ϕ assumes the existence of apreviously created environment of sites, more specifically an environment with a Lock controllingthe access to each critical variable.

ϕ z ≡ let(z)ϕ x ≡ xϕ x = e ≡ let(e) > x > Signalϕ x = e ; st2 ≡ let(e) > x > ϕ(st)ϕ LOCK (x) {st} ≡ xLock.acquire≫ ϕ(st)≫ xLock.release

ϕ LOCALCALL f(x) ≡ F (x)ϕ SYNCCALL s f(x) ≡ s.F (x)ϕ ASYNCCALL s f(x) ≡ Discr(s.F (x),Signal)ϕ ASYNCCALL s f(x) {st} ≡ Discr(s.F (x) > result > ϕ(st),Signal)ϕ IF p THEN {st} ≡ IfSignal(let(p), ϕ(st))ϕ IF p THEN {st1} ELSE {st2} ≡ XOR(let(p), ϕ(st1), ϕ(st2))ϕ WHILE p DO {st} ≡ Loop(let(p), ϕ(st))ϕ st1 ; st2 ≡ ϕ(st1)≫ ϕ(st2)

Function ϕ converts a value or a variable from the language to the correspondent variable orconstant in Orc. A synchronous procedure invocation is translated to a site call in Orc.

The asynchronous procedure call case is not as straightforward as the previous cases. Here, onemust specify in Orc the behaviour of performing a request to a site without blocking for an answerand leaving the rest of the specification to carry on executing. This behaviour can be capturedin Orc by using the previously presented Discr pattern and the fundamental site Signal. TheDiscr pattern executes both arguments in parallel and waits for a signal from any of the sites.Since Signal publishes a signal immediately, the behaviour of the Discr with a Signal argumentis to return immediately leaving the other argument to execute in parallel.

Given the blocking behaviour of the fundamental site if when faced with a false value, onecannot perform a direct translation of the IF THEN statement to the if Orc fundamental site.Such a direct translation would make the entire specification block upon a false value over an ifsite. Thus one uses the IfSignal pattern that never blocks and executes the second expression ifthe predicate evaluates to true.

The behaviour specification of the IF THEN ELSE statement is easier to capture because oneof the branches of the statement is always executed. Therefore, a direct translation to the XORpattern captures the intended behaviour. Similarly to the previous case the WHILE DO statementis captured by the Loop coordination pattern which does not block upon evaluation of false pred-icates.

Given functions ψ and ϕ, specifying the two main phases of the Orc generation process, theoverall generation algorithm is obtained as follows:

β (f(x) {st}) =⎧⎪⎪⎨⎪⎪⎩

F (x) ≜ ψ′1(L,∅)≫ ϕ(L) if ψ1(L,∅) ≠ ι1()

F (x) ≜ ϕ(L) otherwise

5 An example

To illustrate the method introduced in this paper, consider the development of a client applicationto be part of a meteorological network. Instances of this application are to be installed in a numberof geographically separated stations. Each station has at its disposal a set of sensors which providesome meteorological data relative to current weather conditions. The objective of the applicationto be developed is, among other functionalities, to communicate the data read from its sensors toa central server whose purpose is to predict the weather forecast for the next 5 days.


Since the production of weather forecasts is a demanding computational operation, the centralserver will be most of the time devoted to internal activity and only sporadically will interactwith the client stations. Therefore, such communication is required to be asynchronous, to freethe station application for other tasks while not interacting with the server. Another requisite ofthe application to be developed is that since client stations are aware of current weather condi-tions, they must compare the generated forecast with the verified weather conditions and, if greatdiscrepancies are found, ask the central server to check and correct its forecast.

Although this coordination scenario is not unfeasible to be implemented directly, it has stillenough details to justify the previous development of a specification of the communication protocol.Such specification, written in Orc is presented in Fig. 3.

Station()) ≜ Server.CalculateForecast() > fid >GetResult(fid)

GetResult(fid) ≜ GetWeatherConditions() > x >Server.GetForecast(x) > fc >XOR(let(fc == null)

,

RT imer(1000) ≫GetResult(fid),

V erifyResult(fc)VerifyResult(res)) ≜ XOR(¬ ConfirmForecast(res)

,

Server.VerifyForecast(res) > vfcid >GetV erification(vfcid)),

let(res))GetVerification(vfid)) ≜ Server.GetV erifiedForecast(vfid) > vf >

XOR(vf == null

,

RT imer(1000) ≫GetVerification(vfid),

let(vf))

Fig. 3. The Orc specification

Note that in this specification Server is used as the central weather forecast sever. OperationGetWeatherConditions is intentionally undefined (its purpose is to gather local meteorologicaldata). Finally, ConfirmForecast denotes another undefined internal operation intended to dealwith the verification of the generated weather forecast with respect to the current weather condi-tions.

The next step in the development of the station application is to implement the above spec-ification in a programming language. Suppose this task is given to a programmers team whichproduce the following C ♯ code:

1 class Example {

2 private void GetWeatherForecast() {

3 Console.WriteLine("Calculating forecast.");

4 WeatherServer cs = new WeatherServer();

5 int taskId = RequestServerTask(cs);

6 Result res = GetResult(cs, taskId);

7 if(res != null)

8 Console.WriteLine("Forecast: " + res.ToString());

9 else

10 Console.WriteLine("Operation failed");


11 }

12

13 private int RequestServerTask(WeatherServer cs) {

14 Console.WriteLine("Requesting forecast.");

15 Operation op = ...current weather conditions gathering code...

16 int opId = cs.CalculateForecast(op);

17 return opId;

18 }

19

20 private Result GetResult(WeatherServer cs, int opId) {

21 Result res = null;

22

23 while(res == null) {

24 Console.WriteLine("Querying server for forecast.");

25 res = cs.GetForecast(opId);

26 Thread.Sleep(1000);

27 }

28 // Check if the result still needs further calculation

29 if(!ConfirmForecast(res)) {

30 Console.WriteLine("Querying server to confirm forecast.");

31 Operation op2 = ...confirm forecast parameter construction...

32 int op2Id = cs.VerifyForecast(op2);

33 res = GetVerification(cs, op2Id);

34 }

35 return res;

36 }

37

38 private Result GetVerification(WeatherServer cs, int opId) {

39 Console.WriteLine("Querying server for verification result.");

40 Result res = cs.GetVerifiedForecast(opId);

41 if(res == null) {

42 Thread.Sleep(2000);

43 return GetVerification(cs, opId);

44 } else {

45 return res;

46 }

47 }

48 }

This is the point where our method may come to scene: a new Orc specification can beextracted from the source code and compared with the original one. Fig. 4 shows the generatedMSDG. The corresponding CDG, obtained through application of rules

(“CalculateForecast(*);”, (WebService, Sync,Consumer))(“GetForecast(*);”, (WebService, Sync,Consumer))

(“VerifyForecast(*);”, (WebService, Sync,Consumer))(“GetVerifiedForecast(*);”, (WebService, Sync,Consumer))

is represented by the same graph once all dashed vertices have been removed.From this CDG a new Orc specification is derived resorting to the Orc generation strategy

presented in section 4. The result is shown in Fig. 5.Apart some minor differences concerning a few internal names, it is easy to conclude that both

specifications (Fig. 3 and 5) represent the same behaviour in what respects to the invocation of theforeign services (CalculateForecast, GetForecast, V erifyForecast, and GetV erifiedForecast).This conclusion, which is quite trivial for this example, may, in practice require a bit of Orc rewrit-ing to eventually transform both designs into a canonical form, therefore showing (or refuting)their (observational) equivalence.


Fig. 4. Example code MSDG

6 Conclusion

This paper introduced a method that combines a number of program analysis techniques (namely,dependence graphs, program slicing, and graph pattern analysis) to extract the coordination layerof a system from its source code. The whole process is parametric on the type of coordination itabstracts. This feature enables the process, when instantiated with the suitable rules, to extract, forinstance, the web service coordination structure of a system or its distributed object calling model,or even its multithread coordination layer. Further, it is possible to analyse more than one of these


GetWeatherForecast() ≜ new WeatherServer() > cs >RequestServerTask(cs) > taskId >GetResult(cs, taskId)

RequestServerTask(cs) ≜ GetWeatherConditions() > op >cs.GetForecast(op) > opId

let(opId)GetResult(cs, opId) ≜ Null() > res >

Loop(let(res == null),cs.GetForecast(opId) > res >RTimer(1000)) ≫

IfSignal(let(¬ ConfirmForecast(res)),

cs.V erifyForecast(op2) > op2id >GetV erification(cs, op2id) > res >Signal) ≫

let(res)GetVerification(cs, opId) ≜ cs.GetV erifiedForecast(opId) > res >

XOR(let(res == null),

RT imer(2000) ≫GetV erification(cs, opId),

res)

Fig. 5. Orc script extracted from the example code

types of coordination layers, given that the appropriate parametrisation of the communicationprimitives is taken into consideration during to the labelling phase.

Technically our contribution has been to extend previous work (namely [11, 16]) on programgraph representation and devise a strategy for the identification and extraction of coordinationinformation from applications. Related work include [19, 18, 17]. We believe this research is relevantfor the analysis and (formal) certification of OSS, a topic that has been attracting some interestrecently.

In this paper (as well as in its accompanying tool), Orc is used as the specification languagefor the abstracted coordination layers. Note that the Orc generation phase in this method is quitestraightforward, resorting to a small set of Orc behavioural patterns. This can sometimes leadto big and repetitive specifications that demand further simplification to easier understanding ofsome of the aspects of the specified coordination. The whole method can, however, be adapted toother specification languages like CSP [6] or CCS [14]. Moreover, given the stateless behaviour ofOrc site calls, the possibility of resorting to exogenous coordination models like Reo [2] arises asan interesting topic of future work.

Although Orc provides a powerful calculational framework, it would be interesting to tunethe Orc generation process in order to look for more and more complex coordination patternsfrom the outset. Such search, should be based not only on the coordination scripts extracted fromthe Coordination Dependence Graph (CDG), but also on the entire CDG itself, as well as on theoriginal Managed System Dependence Graph (MSDG) which captures other information that maybe relevant to the discovery of more complex patterns. Such is exactly the topic of our currentresearch.

References

1. M. AlTurki and J. Meseguer. Real-time rewriting semantics of orc. In PPDP ’07: Proceedings of the9th ACM SIGPLAN international symposium on Principles and practice of declarative programming,pages 131–142, New York, NY, USA, 2007. ACM.


2. F. Arbab. Reo: a channel–based coordination model for component composition. Mathematical Struc-tures in Comp. Sci., 14(3):329–366, 2004.

3. D. Binkley and M. Harman. A survey of empirical results on program slicing.4. W. R. Cook, S. Patwardhan, and J. Misra. Workflow patterns in orc. In P. Ciancarini and H. Wiklicky,

editors, COORDINATION, volume 4038 of Lecture Notes in Computer Science, pages 82–96. Springer,2006.

5. J. Ferrante, K. J. Ottenstein, and J. D. Warren. The program dependence graph and its use inoptimization. ACM Trans. Program. Lang. Syst., 9(3):319–349, 1987.

6. C. A. R. Hoare. Communicating Sequential Processes. Series in Computer Science. Prentice-HallInternational, 1985.

7. S. Horwitz, T. Reps, and D. Binkley. Interprocedural slicing using dependence graphs. In PLDI ’88:Proceedings of the ACM SIGPLAN 1988 Conf. on Programming Usage, Design and Implementation,pages 35–46. ACM Press, 1988.

8. D. Kitchin, W. R. Cook, and J. Misra. A language for task orchestration and its semantic properties.In CONCUR, pages 477–491, 2006.

9. B. Korel and J. Laski. Dynamic program slicing. Inf. Process. Lett., 29(3):155–163, 1988.10. B. Korel and J. Laski. Dynamic slicing of computer programs. J. Syst. Softw., 13(3):187–195, 1990.11. J. Krinke. Context-sensitive slicing of concurrent programs. SIGSOFT Softw. Eng. Notes, 28(5):178–

187, 2003.12. L. Larsen and M. J. Harrold. Slicing object-oriented software. In ICSE ’96: Proceedings of the 18th

international conference on Software engineering, pages 495–505, Washington, DC, USA, 1996. IEEEComputer Society.

13. D. Liang and M. J. Harrold. Slicing objects using system dependence graphs. In ICSM ’98: Proceedingsof the International Conference on Software Maintenance, page 358, Washington, DC, USA, 1998.IEEE Computer Society.

14. R. Milner. Communication and Concurrency. Series in Computer Science. Prentice-Hall International,1989.

15. J. Misra and W. R. Cook. Computation orchestration: A basis for wide-area computing. Journal ofSoftware and Systems Modeling, May 2006.

16. M. G. Nanda and S. Ramesh. Slicing concurrent programs. In ISSTA ’00: Proceedings of the 2000ACM SIGSOFT international symposium on Software testing and analysis, pages 180–190, New York,NY, USA, 2000. ACM.

17. M. G. Nanda and S. Ramesh. Interprocedural slicing of multithreaded programs with applications tojava. ACM Trans. Program. Lang. Syst., 28(6):1088–1144, 2006.

18. V. P. Ranganath, T. Amtoft, A. Banerjee, J. Hatcliff, and M. B. Dwyer. A new foundation for controldependence and slicing for modern program structures. ACM Trans. Program. Lang. Syst., 29(5):27,2007.

19. V. P. Ranganath and J. Hatcliff. Slicing concurrent java programs using indus and kaveri. Int. J.Softw. Tools Technol. Transf., 9(5):489–504, 2007.

20. N. F. Rodrigues. Generic software slicing applied to architectural analysis of legacy systems. PhDthesis, Dep. Informatica, Universidade do Minho, 2008. (forthcoming PhD thesis).

21. N. F. Rodrigues and L. S. Barbosa. Coordinspector: a tool for extracting coordination data fromlegacy code. In SCAM ’08: Proc. of the Eighth IEEE International Working Conference on SourceCode Analysis and Manipulation. IEEE Computer Society, 2008. to appear.

22. F. Tip. A survey of program slicing techniques. Journal of programming languages, 3:121–189, 1995.23. M. Weiser. Program Slices: Formal, Psychological and Practical Investigations of an Automatic Pro-

gram Abstraction Methods. PhD thesis, University of Michigan, An Arbor, 1979.24. M. Weiser. Programmers use slices when debugging. Commun. ACM, 25(7):446–452, 1982.25. M. Weiser. Program slicing. IEEE Trans. Software Eng., 10(4):352–357, 1984.26. J. Zhao. Applying program dependence analysis to java software. In Proceedings of Workshop on

Software Engineering and Database Systems, 1998 International Computer Symposium, pages 162–169, December 1998.

Certification Infrastructure for theLinux Standard Base (LSB)

Vladimir Rubanov, Denis SilakovInstitute for System Programming of the Russian Academy of Sciences,

Russian Linux Verification Center,{ vrub, silakov}@ispras.ru,

http://linuxtesting.org/

Abstract. Expanding further success of the Linux operating system ishampered by problems with portabilit y of applications across various Linuxdistributions. Identifying and standardizing a common subset of maturefunctionalit y available in most Linux distributions is the target of the LinuxStandard Base (LSB), an interface standard being developed by the LinuxFoundation - the leading international consortium to foster the growth ofLinux. Current LSB status is described with the focus on the technicalcertif ication infrastructure (frameworks for automated development andexecution of LSB compliance tests and the online certif ication system itself).The article emphasizes the critical role of the infrastructure in development ofthe standard itself and in its successful adoption in real world practice.

1. Introduction

Linux proved itself as an industrial strength operating system. It is deployed on anever increasing number of computers from supercomputers, servers and desktops tomobile phones and embedded systems. We are witnessing the extraordinary growthin the Linux community including application developers. However, there are somenegative issues, which need to be addressed. Application developers are faced with alarge and constantly increasing number of Linux distributions from dif ferent vendorsand they need to take into account the many dif ferences between these packageswhen they want to develop applications “for the Linux platform”. That is whydefining Linux as a uniform platform is crucial for keeping the growth and ensuringvitali ty of this operating system.

Removing differences in the core platform services provided by differentdistributions is important for decreasing the costs of developing Linux applications.This directly affects the number of applications available for this platform, which isone of the key characteristics of operating system adoption.

At the moment of writing this article there are 543 (!) different distributionsregistered at http://lwn.net/Distributions/. And this number does not take intoaccount special versions developed for internal company or individual use. But what

80 Vladimir Rubanov, Denis Silakov

is Linux from the application developer’s point of view? It is a combination ofsystem components such as kernel and libraries that work jointly to provideapplication programming interfaces (APIs) to applications. The problem is that everyLinux distribution consists of a unique set of specifi c versions and builds of suchcomponents, which results in that distributions may vary in the number of andbehavior of the provided to applications interfaces both at the API and binary levels.That is why applications that work on one distribution may fail on another andsupporting multiple distributions becomes a serious problem for applicationdevelopers. Of course, it is possible to develop specific versions of an application forparticular distributions but this is rather expensive and may not be affordable forsome developers, which may completely reject supporting Linux platform. Thisinhibits growth of Linux applications and the adoption of the platform itself asdevelopers want to develop applications “f or Linux” not just for RedHat or Suse.

To approach this problem, it was proposed to standardize a common set offunctionality in the main distributions and recommend using only these functionswhen developing portable Linux applications. This would enable portabilit y ofcompliant applications across all compliant distributions.

This article contains two sections. The first one introduces the main industrystandard targeted at solving portabili ty problems for Linux applications - LinuxStandard Base (LSB) [1]. The second section presents the experience and results ofthe Institute for System Programming of the Russian Academy of Sciences(ISPRAS) in building certification infrastructure for this standard. Suchinfrastructure turned out to be extremely important for successful adoption of thestandard.

2. Linux Standard Base (LSB) - the Single Linux Platform

The core idea of the Linux Standard Base (LSB) standard is to describe a subset ofLinux interfaces provided by various libraries that constitute “the Linux platform”from the application developer point of view. This subset should be present in mostLinux distributions and provide compatible services. Description should includeinformation about binary level symbol (ELF name) of each interface and API-levelinformation (parameters, return values and corresponding types) including behaviorspecification of the interfaces. To develop such a standard, a non-profit internationalconsortium was founded in 2000 - Free Standards Group (at present LinuxFoundation [2]), supported by the leading IT companies including IBM, Intel, HP,Novell , and Oracle. The first version of the standard was published in June 2001 andcovered about 3000 interfaces. In the next years the standard grew and matured witheach new version covering more and more interfaces (while excluding someobsolete). The current LSB version is 3.2 and it includes over 30000 interfaces frommore than 40 libraries. Most of the main Linux distributions have now been certifiedfor LSB compliance.

The important thing about LSB is that it does not try to impose somethingcompletely new on Linux distribution vendors. In many cases LSB just refers to

Certif ication Infrastructure for theLinux Standard Base (LSB)

established industry standards and documentation that existing implementationsconform to de-facto. Such referenced specif ications include SUSv3 (POSIX), ISOC99, ISO C++ Language and various documentations maintained by upstreamcomponent developers. And only in the case of missing stable description of aninterface, LSB describes it on its own based on real-world implementation of thisinterface present in the main distributions.

When considering standardization scope, LSB uses the “best practice” criterion.This means an interface becomes a candidate for inclusion in LSB when it is presentin all the main Linux distributions and is actively used by real applications. In otherwords, interfaces for standardization should be quite popular both in the distributionand in the application domains. Also, some technical requirements should be metsuch as that interfaces should have stable implementation, documentation and tests.It is important to note that the role of a vendor-independent international consortiumhelps Linux Foundation to take unbiased decisions when developing LSB.

The modern LSB version 3.2 includes 5 mandatory modules:x LSB Core - low-level system interfaces in C (libc, libcrypt, libdl, libm,

libpthread, librt, libutil, libpam, libz and libncurses libraries).x LSB C++ - standard real-ti me support library for C++ (libstdcxx library).x LSB Desktop - various functions for working with graphical interfaces and

auxili ary services (mainly XML, X11, GTK and Qt).x LSB Interpreted Languages - Perl and Python environment and modules.x LSB Printing - basicall y libcups library.

The first three modules include both generic (architecture independent) andarchitecture specific elements that are roughly structured in the following hierarchy:module->library->group->interface. LSB 3.2 supports 7 architectures - IA32 (x86),AMD64 (x86_64), IA64 (Itanium), Power PC 32, Power PC 64, IBM S390 and IBMS390X. Interpreted Languages and Printing modules have only generic descriptions.

An important factor in understanding the purpose of LSB is that this standard isnot targeted at all Linux distributions and applications. It is for the most of them thatare quite general purpose. Specialized distributions (like embedded) and somesystem applications may not need to be fully LSB compliant. Meanwhile, even if anapplication uses some interfaces beyond LSB then LSB still does matter whendeveloping such application as it allows reducing development costs due to theintersection with LSB that one can rely upon. To enable compatibil ity for thoseinterfaces outside LSB, one can use separate methods like static linking of necessarylibraries or developing special stub proxies that hide dif ferences between differentdistributions. LSB just allows reducing the number of interfaces for which suchspecial means are needed.

81


3. LSB Technical Infrastructure

One of the key success factors for developing and supporting an interface standardlike LSB is a proper technical infrastructure that automates main processes formaintaining the standard itself and that brings the standard closer to real developers.In the particular case of LSB the main components of its infrastructure includegenerators of the standard’s text itself and associated header files based on a centraldatabase, a web portal for LSB developers, analytical and decision support systems,certification tests and frameworks for their effective development, execution, resultanalysis and finally certification. We will give an overview of these systems later inthis section after presenting some historic background.

3.1 LSB Infrastructure Program

The origins of the current team involved in the LSB infrastructure developmentcome from the Open Linux VERification (OLVER) project –http://linuxtesting.org/project/olver. The project was done by the Russian LinuxVerification Center [3] at the Institute for System Programming of the RussianAcademy of Sciences (ISPRAS) [4]. It was funded by the Russian Federal Agencyfor Science and Innovation. We analyzed the text of the LSB Core standard for about1500 Linux system interfaces, delineated elementary assertions and transformedthem into formal specifications in the SeC language from which we then generatedconformance tests for automated testing of Linux distributions against LSB Corerequirements [5].

The OLVER project results turned out to be of high interest for the Linuxcommunity and LSB standard body committee (Free Standards Group at thatmoment), which proposed ISPRAS a long term cooperation for building a new LSBinfrastructure to meet the growing needs of the Linux industry for this standard. Theweak infrastructure that existed at that moment (late 2006) was the most burningpoint for LSB community that hindered wider LSB adoption. In particular, it wascriti cal to improve the certification framework and strengthen test coverage. In early2007, the Free Standards Group merged with Open Source Development Labs andthe newly created Linux Foundation extended cooperation with ISPRAS to covermore infrastructure areas and prepare the jump base for promoting wide LSBadoption. It is important to note that all results (specifications, tools, frameworks)contributed by the Linux Foundation and its partners like ISPRAS to the LSBecosystem are open-source and Linux developers are encouraged to use them andadapt. The first results of the new LSB Infrastructure Program [6] were announced inJune 2007 at the first Linux Foundation Collaboration Summit in Mountain View,CA and since that moment they are being continuously improved with regularreleases. Next in this section we describe the current (June 2008) status of thesedevelopments with focus on the certification related parts.


3.2 LSB Database and Navigator

The backbone of the entire technical LSB infrastructure is the central database(MySQL engine is used) that contains integrated information about the LSB standarditself, about its surrounding Linux ecosystem and various operational mattersincluding certifications. The current database contains 81 tables with over 25 mill ionrecords. There are three parts of the database:

1. The standardization part includes information about LSB elements thatconstitute the essence of the standard itself.

2. The community part contains information about real-world modern Linuxdistributions and applications.

3. The certification part keeps information about the certifi cation status ofvarious products, audit operations, fee payments, etc.

Thestandardization part includes the following elements:x grouping elements:o modules (collections of libraries and commands);o libraries (collections of library groups and headers);o library groups (collections of classes and interfaces);o headers (collections of interfaces, types and constants);

x and leaf elements:o commands;o classes;o interfaces (global variables and public functions);o constants and macros;o types.

These elements are interlinked into a graph of dependencies of various kinds.Information contained in this part of the database is enough to generate completeheader fil es that define all standardized interfaces.

The idea of the community part is to have a single place with “raw” informationabout the Linux ecosystem from the platform standardization point of view.Basicall y it allows understanding which interface elements are provided by particularversions of distributions and which ones are required by various particularapplications.

The certification part supports certification process and is visible to usersthrough the LSB Certified Product Directory (that shows the list of LSB certifiedproducts) and through the online LSB Certification System (that tracks and managescertif ication workflow).

The database is used by various tools, among which one should emphasize over40 scripts that generate LSB deliverables such as the text of the standard itself,header files and various code pieces that are part of implementation of other LSBtools (mainly SDK and tests).

83


To efficiently use the database information from the human point of view, wehave created a web portal that provides user interface and brings the database closerto people. This is a public portal named LSB Navigator (http://linux-foundation.org/navigator/) that provides search, fil tering & browsing capabilities toeffectively find necessary information about the LSB and the Linux ecosystem. Itcan be used by Linux developers, Linux distribution vendors, and LSB workgroup tobrowse, query, analyze and submit feedback. It is important that the LSB Navigatoris used by the LSB workgroup for gathering info when taking decisions about thestandardization scope. Selected features of the LSB Navigator include:x Navigation through the standardized LSB elements from modules down to

leaf elements like interfaces and constants.x Global fil ters for LSB version and hardware architecture.x Individual home pages for over 1 mill ion Linux interfaces (each is just 2-

click away from the main page via search) that include information on:o status of each interface in terms of LSB (in LSB, never been in LSB,

planned for inclusion, withdrawn, deprecated);o LSB info (module, library, header fil e, etc.);o interface signature (parameters and return value);o direct link to documentation of the interface;o which distributions provide this interface;o which applications use this interface;o which tests are available for this interface;o community discussions related to the interface.

x Distribution info (provided libraries and interfaces).x Application info (external libraries and interfaces required by each app).x Statistics on LSB elements (total numbers of interfaces, commands, classes in

each LSB version).x Statistics on interface usage by applications:o which interfaces are most frequently used by different applications (list of

interfaces with info on how many applications use each interface);o which libraries are most frequently used by different applications (list of

libraries with info on how many applications use each library);o LSB “rating” of registered applications (list of applications with info on the

number of LSB and non-LSB libraries and interfaces used by eachapplication).

An important idea in the context of supporting certifi cation is that the LSBNavigator serves as an online reference and a knowledge base for the LSB standard.Other systems can easily use links to specific pages in the Navigator thus providingan integrated environment for users.

3.3 LSB Certification Tests

Ian Murdock, the former LSB Chair, said: “An interface standard is only as good asits test suites”. In late 2006, the LSB test coverage was about 15%, which means that

Certif ication Infrastructure for the Linux Standard Base (LSB)

85% of standardized interfaces did not have tests at all. That is why developing newtests that check conformance of distributions against the requirements of LSBstandard was the first priority to enable real lif e value of this standard. The problemis that the number of interfaces in the LSB is too huge to develop tests of excellentquali ty for all of them. To create a feasible strategy for developing LSB tests, wedefined three testing qualit y grades (the borders between the testing grades areobscure as the scale is actually continuous):1. Shallow – simple tests with the only guaranteed purpose of ensuring the

interface does not crash (sometimes it is additionally checked that the interfacedoes not return an error code) being called with some particular correctparameters and in the correct environment. This is close to “existence” or“smoke” or “sanity” tests (but beware - these terms are interpreted differently bydifferent experts).

2. Normal – this is the most reasonable level of testing achievable by tests writtenin plain C. The tests check the main functionality and may check a few errorscenarios. Most of the legacy LSB tests are of this quality.

3. Deep – this is the level when most of the specification assertions are tested invarious conditions/states. This is usuall y done for most important and criticalsoftware.

To develop tests of corresponding grades, we are using dif ferent approaches.For shallow tests, we developed a new technology and tools (AZOV

Framework) for automatic generation of shallow tests based on some description ofthe interfaces, their parameters, dependencies and default values in the LSBdatabase. The core idea here is to augment the database to contain enoughinformation about the interfaces and their dependencies that would allowautomaticall y building correct call chains representing typical scenarios of interfaceusage. The first version of the shallow testing framework is ready and is now beingused for Qt tests development. The cost of developing shallow tests is mainly inpopulating the information in the database + debugging automatically generatedtests.

Normal tests are basicall y manual C tests, though we do use some automationhere as well. We have been inspired by the generator that we found in the existingLSB tests for GTK – gtkvts. Basicall y, it allows automaticall y generating many testinstances based on the same parameterized code thus achieving better testing qualit ywithout duplicating the code. However, we found particular gtkvts implementationlimi ted and we used only the idea while implemented our own tools andmethodology called T2C (template-to-C). The first version of the T2C Framework isready and is now being used for developing GTK, C++ and X11 tests.

Deep level of testing is hard to achieve by manual tests in C; so advanced testingtechnologies are necessary here. We use our own ISPRAS UniTESK technology forthis. It is based on a model-based testing technique where requirements for the targetsystem are expressed as formal specifications in a special language (SeC inUniTESK) and then various test actions are automatically generated on-the-fly from

85


test scenarios. Our former project OLVER (see 3.1 above) was based on thistechnology and now we are adapting/improving it to become official LSB tests forthe LSB Core part.

For the normal and deep tests, it is important to have linkage to the text of thespecification assertions. This means when a test fails it should say which particularassertion in the standard’s text is violated as well as provide info about particularmismatch (like XX expected, YY returned). Normal and deep tests being developedin ISPRAS do have this feature and analyzing reports and debugging failures is mucheasier with this approach. Leveraged by a visual execution environment andinteractive HTML reports this gives unprecedented comfort for the users. Apart frombetter reporting, the assertion catalog also enables measuring test coverage in termsof the number of assertions checked by the tests, which gives an advanced level oftest quality measurement.

Currently, there is a testing strategy being implemented by ISPRAS to achievealmost 100% test coverage for LSB interfaces by the end of 2008 but with most ofthe tests of shallow quality. The target for the end of 2009 is to cover most of thelibraries with normal quality tests and the most important part (LSB Core) with deepqualit y tests.

3.4 LSB Certification Tools

To make LSB certification and testing technically appealing, it is important tohave user-friendly systems that support these processes. As a part of the LSBInfrastructure program in early 2008 we created a new web-based Certif icationSystem that guides people certifying their products through the certifi cationworkflow and keeps records for certifi ed products. The new certification systemincludes three major parts:x Certification Management provides step-by-step instructions on what to do and

enables easy status tracking and collaboration with LF staff during thecertification process for companies and individuals who want to certif y theirLinux distributions or applications against LSB.

x Product Directory is a public part of the Certification System that contains thecurrent list of LSB-certified Linux distributions and applications with variousviews and groupings.

x Problem Reporting is for online collaboration on solving problems arising in theprocess of certification. It also provides a knowledge base of various issues andsolutions.

There is also Administration Mode that allows managing the certification systemfrom the LF side with full rights on administering all the data.

Finall y, at the technical level of certifi cation process it is necessary to be able tosmoothly execute automated tests and analyze the results. For this purpose, we havedeveloped Distribution and Application Testkit Managers (DTK and ATKManagers) for testing distributions and applications respectively. These tools are


web-based with embedded simple web-server. ATK Manager is also known as LinuxApplication Checker.

The tools represent test execution frameworks that have the following keyfeatures:

x integrated user interface for all the LSB test suites (web based andcommand line);

x selection of tests to run (all, manually selected subset, predefined subsets,etc.);

x saving/loading configured options in user profiles for quick test runs in thefuture;

x automatic download of missing test suites from the Linux Foundation FTPsite;

x 'one-click execution of certification tests;x unified test reports with links to the knowledge base of known issues and to

home pages of interfaces in the LSB Navigator for more informationincluding community discussions;

x management of test results history.

Further, the ATK Manager provides features for application analysis without regardto the certification process. These features include viewing the list of all externallibraries and interfaces required by an application with status in LSB perspective (ifin the LSB or not). In particular, this allows detecting unused libraries present inDT_NEEDED section of the application under analysis but without actual interfacesused by the application in such libraries.

The online certification system and ATK/DTK Mangers are integrated toprovide transparent switches between local and the LF central-server basedfunctionality to provide an easy to use complete certification process.

4. Conclusion

Problems of application portabilit y among different Linux distributions prove tobe one of the most important factors that inhibit the growth of the number ofapplications available for Linux and thus prevent developing further success of theLinux platform as a whole. In this paper we have considered the Linux StandardBase open standard, which is the primary modern effort to address this problem. Anumber of industry companies initiated this activity to standardize a common subsetof Linux functionalit y that most applications can rely upon. Currently the LSBstandard is developed by the Linux Foundation international consortium withfunding of such companies as IBM, Intel, HP, Novell, Oracle, etc.

In order to develop a good interface standard such as LSB it is crucial to have aproper technical infrastructure. The Linux Foundation jointly with the Institute forSystem Programming of the Russian Academy of Sciences are developing such aninfrastructure for the LSB standard.

87


The current results of this cooperation include new production versions of thefollowing systems:x Central LSB Database & various data transformation scripts.x LSB Navigator – a web portal on top of the central LSB database with

advanced navigation, queries, community collaboration mechanisms,developers’ feedback and contribution interface to promote information aboutthe LSB and surrounding ecosystem and also for making decisions on theLSB standardization scope.

x LSB DTK and ATK Managers – to automate Linux distribution andapplication certification testing in a user friendly way.

x LSB Certification System (integrated with the ATK/DTK Managers) - tosupport and facilitate LSB certification workflow.

x Misc. auxil iary tools for automating investigation and analytical tasks.x New testing technologies and tools for automated test development of various

quality grades:o UniTESK for deep testing (ISPRAS owned technology with over 10 years

history).o T2C – methodology and tools for normal tests development (developed

speciall y for the LF on top of TET harness and ideas of gtkvts .inp files).o Azov – innovative methodology and tools for automated massive

development of shallow tests based on extended information from thecentral LSB database (developed specially for the LF).

x New tests for more than 19000 of LSB interfaces.

The developed infrastructure is being used in real li fe and has been getting manypositive responses. Meanwhile, there are plans to improve many issues - first of all,mature all the tools and achieve 100% test coverage of the LSB interfaces. This willhelp making the LSB standard the acknowledged “single Linux platform” that reallymitigates application portabilit y problems, which wil l clear the way for furtherexpansion of Linux.

5. References

[1] Linux Standard Base Homepage.http://www.linuxfoundation.org/en/LSB/.

[2] Linux Foundation.http://l inuxfoundation.org/

[3] Linux Verification Center. http://linuxtesting.org/[4] Institute for System Programming of the Russian Academy of Sciences.

http://ispras.ru/[5] V. Kuliamin, A. Petrenko, V. Rubanov, A. Khoroshilov. Formalization of

Interface Standards and Automatic Construction of Conformance Tests.Proceedings of SECR 2006 conference, Moscow.

[6] LSB Infrastructure Program.http://ispras.linuxfoundation.org/

Documents

4)* + -,.#&a bAci.unu.edu/media/publication/000/001/421/report398.pdf · Over the last decade, the importance of Free/Libre/Open Sou rce Software (FLOSS) ... International Workshop