Perfis de Segurança em Sistemas de Tempo Real e Mecanismos de Verificação

8/4/2019 Perfis de Segurana em Sistemas de Tempo Real e Mecanismos de Verificao

1/57

Enquadramento Mecanismos de Verificao Solues Industriais Solues Acadmicas

Perfis de Segurana em Sistemas de Tempo Real eMecanismos de Verificao

Joel Silva Carvalho

Mestrado em Engenharia InformticaOritentao: Prof. Simo Melo de Sousa

RESCUE - 22/10/2008

1 / 57Perfis de Segurana em Sistemas de Tempo Real e Mecanismos de Verificao


2/57


ndice1 Enquadramento

IntroduoPerfil de Segurana Ravenscar

2 Mecanismos de VerificaoVerificao de Modelos

UPPAAL

Verificao Esttica3 Solues Industriais

SPARK4 Solues Acadmicas

LET - Logical Execution Time

GiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language



3/57





UPPAAL







4/57


Objectivos

Apresentar mtodos de verificao aplicveis aos sistemas detempo real.

Revelar e classificar algumas linguagens baseadas no modeloLET (Logical Execution Time).

Potenciar um ponto de partida para um debate sobre ProofCarrying Code para sistemas embebidos (de tempo real ouno).



5/57


Timeline



6/57





UPPAAL







7/57


Introduo

Em 1997 na 8th International Real-Time Ada Workshop (IRTAW)ficou definido o perfil Ravenscar.

Este perfil destina-se aos sistemas de tempo real crticos econsiste numa coleco de primitivas concorrentes e derestries linguagem Ada.

O Ravenscar permite um desenvolvimento eficiente eaplicaes capazes de serem verificadas quer na suacomponente funcional como temporal.

de notar que o perfil pode e aplicado noutras linguagenscomo o Java e o C.



8/57


Motivaes

Suporte da concorrncia ao nvel da linguagem permitindoverificao esttica pelo compilador e outras ferramentas.

Aumento da eficincia reduzindo a utilizao de funcionalidadescom um overhead elevado.

Reduo de situaes no deterministas nas aplicaescrticas.

Possibilidade de utilizao de kernels simplificados, ou sejamais eficientes.

Remoo de funcionalidades de fraco suporte na verificaoformal.

Remoo de funcionalidades que inibem anlises temporaisefectivas.



9/57


Descrio resumida do perfil

Declarao de tarefas e objectos protegidos apenas possvel aonvel da biblioteca.

No permitida a alocao dinmica quer de tarefas como deobjectos protegidos.

S so permitidos objectos protegidos com uma ou nenhumaentrada.

As tarefas so assumidas como no terminais.

Apenas uma tarefa pode ser colocada na fila de uma entrada.

No permitida a reposio de elementos numa fila.



10/57


Descrio resumida do perfil

No permitido o uso de instrues abort ou ATC(asynchronous transfer of control).

No permitida a utilizao de estruturas de controle Select.

Na construo de tarefas peridicas no deve ser utilizada ainstruo delay mas sim delay until.

Apenas necessria a utilizao do pacote Real-Time, o pacotecalendrio no pode ser utilizado.

Pragmas (directivas de compilao) atmicas e volteis.

No permitido o uso de prioridades dinmicas.


E d M i d V ifi S l I d i i S l A d i


11/57



Introduo

Perfil de Segurana Ravenscar2 Mecanismos de Verificao

Verificao de ModelosUPPAAL






E d t M i d V ifi S l I d t i i S l A d i


12/57


Introduo

Os sistemas de tempo real so frequentemente parte de umsistema crtico mais vasto o que enfatiza a utilizao demtodos formais.

Estes mtodos devem acompanhar todo o processo de

desenvolvimento sendo recorrente conjugar vrios deles.Um dos mtodos que devem ser utilizados no desenvolvimentode sistemas de tempo real a verificao de modelos combase na lgica temporal. De notar que esta lgica divide-seem diversas famlias com expressividades distintas.

Nem todas as ferramentas de verificao de modelos utilizam amesma lgica temporal.




13/57


Motivao 1

Mtodos de verificao diferentes permitem, muitas vezes,validar propriedades distintas.

Sem uma modelao correcta dificilmente se conseguedesenvolver um sistema correcto.

Os sistemas de tempo real requerem uma anlise temporal(Timing Analysis) exaustiva que pode e deve ser feita numafase inicial do desenvolvimento.

A verificao de modelos no entanto limitada e insuficiente

uma vez que apenas permite verificar algumas regras temporaise asseres de segurana.

1A comparative Study of Formal Methods for State Based Systems




14/57


Propriedades passveis de serem verificadas2

Segurana (Safety)

Em certas condies, um determinado acontecimento no

pode ocorrer.

Acessibilidade (Reachability)

Uma situao particular pode ser atingida. Pesquisa emforward chaining ou backward searching do grafo de

acessibilidade.

2Verificao Formal - Lus Descalo




15/57


Propriedades passveis de serem verificadas2

Razoabilidade (Fairness)

Em certas condies, um determinado evento vai ocorrer (ouno vai ocorrer) uma infinidade de vezes.

Vivacidade (Liveness)Em certas condies, um determinado evento vai acabar poracontecer.

Ausncia de DeadLockO sistema no pode chegar a uma situao a partir da qualnenhum progresso possvel.

2Verificao Formal - Lus Descalo




16/57


Algumas ferramentas 1 3

RT-Spin

Extenso da linguagem promela com noes temporais eLgica LTL com asseres. Adequado para sistemas

concorrentes interactivos.Kronos e UPPAAL

Autmatos temporizados (Lgica temporal TCTL). Adequadospara sistemas de tempo real.

1A comparative Study of Formal Methods for State Based Systems3Vrification de logiciels: Techniques et outils du model-checking




17/57


Algumas ferramentas 1 3

SMV

Autmatos temporizados (lgica temporal CTL). Adequadopara sistemas concorrentes.

HyTech

Autmatos Hbridos Lineares. Adequado para sistemasembebidos crticos.

1A comparative Study of Formal Methods for State Based Systems3Vrification de logiciels: Techniques et outils du model-checking




18/57

q

UPPAAL 1 4 5

Proclamada como sendo uma das ferramentas de verificao de

modelos mais utilizadas nos sistemas de tempo real.Utiliza extenses dos autmatos temporizados compropriedades acrescidas, como constantes inteiras, variveisinteiras limitadas, variveis booleanas, canais de sincronizaoe outras.

Lisonjeada pela sua interface grfica e pela sua capacidadede simulao, funcional mesmo para sistemas de grandedimenso onde a verificao no possvel (exploso deestados).

Permite a definio/criao de autmatos tanto por interface

grfica como por formato textual prximo das linguagens deprogramao. Bem como a transformao de autmatoshbridos lineares em redes de autmatos temporais.

1A comparative Study of Formal Methods for State Based Systems4UPPAAL - a Tool Suite for Automatic Verification of Real-Time Systems

5A tutorial on UPPAAL 18 / 57Perfis de Segurana em Sistemas de Tempo Real e Mecanismos de Verificao



19/57

q

UPPAAL - Two Doors

Uma sala possui duas portas que no podem ser abertas aomesmo tempo.

Cada porta abre quando o respectivo boto premido.

As portas demoram 6 segundos a abrir e outros 6 a fechar.Cada porta no pode estar aberta nem menos de 4 segundosnem mais de 8 segundos.

Cada porta aps ser fechada tem de permanecer fechada

durante pelo menos 5 segundos.




20/57

UPPAAL - Two Doors, Verificao

E Door1.open | Acessibilidade - A Porta 1 abre.

E Door2.open | Acessibilidade - A Porta 2 abre.

Door1.wait > Door1.open | Vivacidade - Quando o boto daporta 1 premido a porta 1 eventualmente abre.

Door2.wait > Door2.open | Vivacidade - Quando o boto daporta 2 premido a porta 2 eventualmente abre.

A[] not deadlock | Ausncia de deadlock - O sistema est livrede deadlocks.

A[] not (Door1.open and Door2.open) | Segurana - As duas

portas nunca esto abertas ao mesmo tempo.A[] (Door1.opening imply User1.w


21/57


Introduo










22/57

Motivao

Utilizao posterior fase de modelao, este tipo deverificao est correlacionada com a linguagem dedesenvolvimento.

A verificao esttica refina a verificao de modelos umavez que faz verificao ao nvel do cdigo, mais precisamentena fase de compilao.

Possibilidade de associar um selo de qualidade (certificado)ao cdigo.




23/57


Introduo










24/57

SPARK - SPADE Ada Kernel

Linguagem de programao desenvolvida pela Praxis combase no Ada.

Desde sempre segue uma abordagem correcta por construo(Correctness by Construction) recorrendo a anotaes (pr,ps condies e outras).

Em 2003 foi adoptado o perfil ravenscar para permitir odesenvolvimento de aplicaes concorrentes.

Permite uma extensa anlise esttica incluindo anlises defluxo de controlo, de dados e informao e recorre a umprovador de teoremas que verifica outras propriedades

matemticas.

Num modelo de desenvolvimento tradicional o Spark nosubstitui nem dispensa o processo de modelao.




25/57

Spark Examiner

A primeira tarefa do Examiner consiste em analisarlexicalmente e sintacticamente cada unidade de compilao.

Na segunda tarefa feita uma anlise semntica de cadaunidade de compilao.

Posteriormente feita uma anlise de fluxo de controlo quepermite verificar se o cdigo est bem estruturado.

De seguida feita a anlise de fluxo de dados e informaopara controlar a estabilidade dos ciclos, a no existncia devariveis declaradas mas no utilizadas, instrues sem efeito,utilizao de variveis no inicializadas e a consistncia entre ofluxo de informao esperado e o actual.




26/57

Spark Examiner

Por fim feita uma deteco de erros que podem ocorrer emtempo de execuo (diviso por zero, ndice fora do tamanho,etc.) e so geradas obrigaes de prova sobre essespossveis erros.

Algumas das obrigaes de prova so descartadas com umaferramenta automtica (o Spark Simplifier) e as restantesdevero ser provadas recorrendo ao SPADE Proof Checker.

A verificao feita pelo SPARK Examiner engloba ainda umaanlise capaz de determinar o pior caso deexecuo(WCET).




27/57

The Tokeneer Project1

O Tokeneer ID Station (TIS) uma estao confivel eauto-suficiente responsvel por validar identificaesbiomtricas de utilizadores.

9939 Linhas de cdigo.

260 Dias de trabalho.

203 Linhas de cdigo produzidas por dia, na fase deprogramao.

1 Defeito descoberto desde a entrega.

1http://www.adacore.com/home/gnatpro/tokeneer/


http://www.adacore.com/home/gnatpro/tokeneer/http://www.adacore.com/home/gnatpro/tokeneer/


28/57

Algumas anotaes

global Torna visvel uma varivel global com o modoespecificado.

1 procedure Control;2 # g l o b a l i n S en so r . S t a t e ; 3 # o u t V a lv e . S t a t e ;

derives Especifica o fluxo de informao entre os parmetros evariveis globais de um procedimento.

1 procedure Flt_Integrate(Fault : in Boolean;2 Trip : in out Boolean;3 Counter : in out Integer)4 # d e ri v es T r i p fr om , F a u lt , C ou nt er &5 # C o un t er f r om , F a u l t ;




29/57

Algumas anotaes

pre Requisito essencial para o correcto funcionamento doprograma.

post Resultado garantido aps uma correcta execuo.

assert Utilizado para especificar condies que devem ser

sempre verdadeiras.1 procedure Div(M, N: in Integer; Q, R: out Integer)2 # d e r i ve s Q, R f r om M, N ; 3 # p re (M >= 0 ) and (N > 0 ) ; 4 # p os t (M = Q N + R) and ( R < N) and ( R >= 0 ) ; 5 is6 begin7 Q : = 0 ; R : = M ;8 loop9 # a s s er t (M = Q N + R) and (R >= 0 ) ;




30/57

Cdigo Exemplo1 package Example2 ...

3 is4 task type Producer;5 # d e cl a r e p e ri o d = > ( 2 00 ); 6 P e r i o d i c i d a d e da t a r e f a = 2 00ms 7 # d e cl a r e d e ad l in e = > ( 2 00 ) ; 8 Tempo mximo para execuo da ta re fa = 200ms9 ...

10 end Example;11 ...1213 if Device = smart then14 delay until next+Ada.Real_Time.milliseconds(70);15 e n ab l e d e v i c e 16 Current := Ada.Real_Time.Clock;17 delay until Current+Ada.Real_Time.Milliseconds(30);18 r ea d f r om d e vi c e a nd c o n s t r u c t d a ta 19 Input Data.Write(Data);20 # d e c l a r e d e a d l i n e = > ( N ex t+Ada . R ea l_ Ti me . M i l l i s e c o n d s ( 1 3 0 ) ) ; 21 else22 for Count in 1..10 loop23 e n ab l e d e v i c e 24 Current := Ada.Real_Time.Clock;25 delay until Current+Ada.Real_Time.Milliseconds(2);26 r e ad f r om d e v i c e 27 # d e c l a r e d e a d l i n e = > ( C u r r e n t +Ada . R ea l_ Ti me . M i l l i s e c o n d s ( 4 ) ) ; 28 ...




31/57


Introduo





LET - Logical Execution TimeGiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language




32/57

LET - Logical Execution Time 1

Abstraco que est na base de todas as linguagens que voser apresentadas, no entanto surgiu com o desenvolvimento doGiotto.

LET significa que o comportamento temporal de uma tarefa independente da sua execuo fsica.

1Trends in Embedded Software Engineering




33/57


Considera-se que se a execuo fsica for suficientementerpida para se enquadrar nos intervalos lgicos de incio e fimde tarefa ento a execuo time-safe.

S aps o evento de terminao lgico que os resultados datarefa podem ser acedidos por outras tarefas, mesmo que aexecuo fsica seja finalizada antes.

De forma semelhante so introduzidos na memoria atribuda tarefa os valores de entrada, aquando do evento de

inicializao lgico e no do inicio fsico da tarefa.




34/57


Introduo





LET - Logical Execution TimeGiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language



1 2


35/57

Giotto 1 2

Modelo abstracto baseado numa linguagem de programaopara sistemas embebidos com tarefas peridicas.

Este modelo consiste num compilador e num ambiente deexecuo independente.

A sua principal caracterstica reside na abstraco que feita aonvel da arquitectura. feita uma diviso entre a parte lgica(quer funcional como temporal) e a parte fsica na qual ocdigo vai ser executado tornando os programascompletamente independentes da plataforma.

1Giotto2Giotto: A Time-triggered Language for Embedded Programming



2


36/57

Tasks 2

As tarefas representam a funcionalidade de base de umprograma Giotto. Elas so executadas em intervalos de temposregulares (tarefas peridicas).

As tarefas possuem um nmero arbitrrio de portas de

entrada e sada.A cada tarefa associada uma funo implementada por umprograma sequencial escrito em qualquer linguagem.

Para a implementao de um programa Giotto numa dadamquina o compilador necessita conhecer o WCET da

funo em cada unidade de processamento.

2Giotto: A Time-triggered Language for Embedded Programming



M d 2


37/57

Modes 2

Um programa Giotto consiste num conjunto de modos, no qual repetido periodicamente um conjunto de tarefas predefinido.

Um programa s pode estar num modo de cada vez.Um modo pode ainda conter instrues para passagem aoutro modo.




P t D i 2


38/57

Ports e Drivers 2

Um porto representa uma varivel tipada num espaopartilhado.

Esse espao pode ser de memria partilhada ou de outro tipo.

Cada porto persistente no sentido que mantm o seu valorao longo do tempo at ser actualizado.

Os Drivers so o que permitem a comunicao entre osportos das tarefas.




A t 2


39/57

Anotaes2

Enquanto o designado cdigo puro do Giotto independenteda plataforma esse mesmo cdigo pode ser refinado comdirectivas de compilao na forma de anotaes.

Essas directivas podem mapear uma determinada tarefa paraum unidade de processamento, escalonar uma tarefa numintervalo de tempo ou ainda escalonar um evento decomunicao entre tarefas num intervalo de tempo.

De notar que estas anotaes no influenciam asfuncionalidades do programa apenas introduzem indicaes

ao compilador com utilidade na fase de implementao numadada plataforma.




Anotaes2


40/57

Anotaes2

Existem trs nveis de anotaes no Giotto. O primeirodesignado por Giotto-H (H de Hardware) no qual especificado o conjunto de unidade de processamentodisponveis, as redes e informaes sobre os WCET de cadatarefa e outras informaes sobre os tempos de comunicao.

O segundo nvel designado por Giotto-HM (M de Map) eneste acrescentada informao sobre o mapeamento entre astarefas e as unidades de processamento.

O terceiro e ltimo nvel designado por Giotto-HMS (S deScheduling) e especifica em adio informaes sobre o

escalonamento de cada unidade de processamento.De notar que estas anotaes variam consoante o RTOS dedestino.




Verificao3


41/57

Verificao3

Uma das formas apresentadas para fazer verificao deprogramas Giotto consiste num esquema de traduo domodelo para redes de autmatos temporizados (maisprecisamente para a ferramenta de verificao de modelos

UPPAAL).Este esquema de traduo divide-se em duas partes. Numaprimeira considerado apenas o cdigo puro do Giotto (sem asanotaes) e numa segunda parte so consideradas asanotaes.

3Verification of Giotto Based Embedded Control Systems



Exemplo Single CPU Helicopter 4


42/57

Exemplo - Single-CPU Helicopter 4

4http://embedded.eecs.berkeley.edu/giotto/



Exemplo Two CPU Helicopter 4
http://embedded.eecs.berkeley.edu/giotto/http://embedded.eecs.berkeley.edu/giotto/


43/57

Exemplo - Two-CPU Helicopter 4




E Code 4


44/57

E-Code




ndice


45/57


Introduo



Verificao Esttica

3 Solues IndustriaisSPARK

4 Solues AcadmicasLET - Logical Execution TimeGiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language



SCC - Schedule Carrying Code1


46/57

SCC - Schedule Carrying Code

Do processo de compilao do Giotto obtemos o designadoE-Code (Embedded Code) que executado numa mquinavirtual, a E-Machine. Este E-Code time-safe se forencontrado um escalonamento possvel para a plataforma naqual se quer implementar a aplicao.

O SCC introduz um conceito novo que d origem ao S-Code(Scheduling Code), isto , uma linguagem mquina executvelque permite especificar o escalonamento.

Ao contrrio do que acontece no Giotto original neste modelotemos o E-Code que independente da plataforma e o S-Code

que passa a ser dependente da plataforma mas que valida aexecuo do E-Code dentro dos requisitos temporais.

1Schedule-Carrying Code



SCC - Schedule Carrying Code 1 2


47/57

SCC - Schedule Carrying Code

O S-Code s gerado se for encontrado um escalonamentoque considere a execuo do programa como time-safe. Estecdigo pode ser visto como uma prova de escalonamento(Schedulabity Proof) para uma determinada plataforma.

O S-Code consiste ento num conjunto de instrues que

determinam qual a tarefa a ser executada at que umdeterminado evento ocorra. Esse evento pode estar relacionadocom o relgio, com uma tarefa ou at mesmo com um sensor.

O S-Code pode ser gerado consoante qualquer estratgia deescalonamento em tempo de compilao, execuo ou

parcialmente em compilao e parcialmente em execuo.

1Schedule-Carrying Code2The Context of Schedule Carrying Code



Exemplo 1 2


48/57

Exemplo

1Schedule-Carrying Code2The embedded machine: predictable, portable real-time code.



ndice


49/57


Introduo

Perfil de Segurana Ravenscar2 Mecanismos de VerificaoVerificao de Modelos

UPPAAL

Verificao Esttica


4 Solues AcadmicasLET - Logical Execution TimeGiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language



TDL - Timing Definition Language 1


50/57

TDL Timing Definition Language

Linguagem de programao baseada nos princpios do Giottomas que fornece uma sintaxe mais conveniente e um conjuntode ferramentas alargado.

Tanto o compilador como a E-Machine do TDL foram feitos semrecurso ao cdigo do Giotto, tendo sido feitas as alteraesconsideradas fundamentais para uma possvel aplicao emtermos industriais.

O TDL acrescenta um novo conceito relativamente ao Giotto.Trata-se da arquitectura baseada em componentes(mdulos). Isto proporciona uma maior flexibilidade na

construo de programas uma vez que os mdulos soindependentes, os mesmos podem no entanto ser referenciadosentre eles e utilizados com mltiplos propsitos.

1TDL Specification and Report



Exemplo 2


51/57

Exemplo

2The Timing Definition Language (TDL)

51 / 57

Perfis de Segurana em Sistemas de Tempo Real e Mecanismos de Verificao


ndice


52/57

1 EnquadramentoIntroduo


UPPAAL

Verificao Esttica


4 Solues AcadmicasLET - Logical Execution TimeGiotto

SCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language

52 / 57



xGiotto - eXtended Giotto 1 2


53/57

O xGiotto surgiu pelas mos dos criadores do Giotto comouma extenso do mesmo que se liberta da dependncia dossistemas de tarefas peridicas. Esta linguagem suporta emadio a utilizao de eventos assncronos.

O xGiotto introduz ainda a F-Machine na qual definido ocdigo funcional das tarefas.

De notar que o xGiotto realiza vrias anlises de integridade.A primeira visa rejeitar programas que contenham possveisrace conditions, isto ,detecta quando duas tarefas soterminadas por um mesmo evento que escrevem no mesmoporto. Numa segunda anlise feita uma previso sobre a

capacidade de memria necessria. Na terceira anlise verificada a time-safety do programa numa determinadaplataforma.

1xGiotto Language Report2Event-driven Programming with Logical Execution Times

53 / 57



Exemplo 2


54/57

p

2Event-driven Programming with Logical Execution Times

54 / 57



ndice


55/57

1 EnquadramentoIntroduo


UPPAAL

Verificao Esttica

3 Solues IndustriaisSPARK4 Solues Acadmicas

LET - Logical Execution TimeGiotto

SCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language

55 / 57



HTL - Hierarchical Timing Language 1


56/57

O HTL outra linguagem que teve por base o Giotto e nestemomento tudo me leva a crer que pode ser considerado como osucessor do xGiotto (alguns dos criadores desta linguagemesto na base do Giotto e do xGiotto).

O HTL mais flexvel que o Giotto e suporta por baseprecedncia de tarefas bem como refinamentos hierrquicos.

Como vantagem sobre o xGiotto o HTL consegue simplificar oprocesso de prova de time-safety muito devido sua estruturahierrquica. Num programa HTL basta garantir que o modelo

time-safe ao nvel mais alto.

1A Hierarchical Coordination Language for Interacting Real-Time Tasks

56 / 57



Esquema 1


57/57

1A Hierarchical Coordination Language for Interacting Real-Time Tasks

57 / 57


Perfis de Segurança em Sistemas de Tempo Real e Mecanismos de Verificação

Documents

Transcript of Perfis de Segurança em Sistemas de Tempo Real e Mecanismos de Verificação