BRPI0618027A2

BRPI0618027A2 - configuração de extensões isoladas e acionadores de dispositivo

Info

Publication number: BRPI0618027A2
Application number: BRPI0618027-2A
Authority: BR
Inventors: James R Larus; Orion Hodson; Steven P Levi; Bjarne Steensgaard; David R Tarditi; Michael Spear; Michael Carbin; Martin Abadi; Mark Aiken; Paul Barham; Ted Wobber; Brian Zill; Chris Hawblitzel; Nick Murphy; Galen C Hunt; Manuel A Fanndrich
Original assignee: Microsoft Corp
Priority date: 2005-10-26
Filing date: 2006-10-16
Publication date: 2011-08-16
Also published as: WO2007050364A1; KR101331361B1; JP2009514099A; RU2443012C2; EP1952251A1; EP1952251A4; RU2008116714A; KR20080070634A; US20070094673A1; JP5009299B2; US8074231B2

Abstract

CONFIGURAçãO DE EXTENSõES ISOLADAS E ACIONADORES DE DISPOSITIVO Descritas aqui estão uma ou mais implementações para descrever e/ou abordar as exigências de configuração de aplicações, extensões, acionadores de dispositivo (300) , e outros componentes de um sistema de software.

Description

"CONFIGURAÇÃO DE EXTENSÕES ISOLADAS E ACIONADORESDE DISPOSITIVO"

Fundamentos da Invenção

Sistemas de software, tal como os sistemas opera-cionais, tipicamente vêm com um conjunto pré-definido de mó-dulos de software para executar várias tarefas. Esses módu-los estão associados uns com os outros porque eles são todosparte do mesmo conjunto pré-definido.

Entretanto, funcionalidade adicional e/ou persona-lização são freqüentemente desejadas. Em outras palavras, afuncionalidade é "estendida". Tipicamente, os sistemas desoftware permitem extensão fornecendo adição dinâmica de no-vos módulos ou processos de software. Essas adições são fre-qüentemente chamadas "extensões" ou "conexões" ("plug-ins").Exemplos comuns de extensões ou conexões em sistemas conven-cionais incluem, mas não estão limitados a, acionadores dedispositivos para sistemas operacionais, procedimentos es-tendidos armazenados em bases de dados, conexões e controlesActiveX™ em navegadores da rede, conteúdo ISAPI e extensõesde filtro em servidores da rede, extensões de invólucro parainvólucros de interface de usuário, etc. A funcionalidadeadicionada por extensões está na faixa de simples suportepara versões atualizadas de dispositivos de hardware a var-redores de virus para ferramentas de fluxo de trabalho emclientes de correio eletrônico. Entretanto, a aproximaçãoconvencional para integrar extensões pode ser problemática.

Por exemplo, um sistema operacional convencional("OS") carrega extensões carregando um conjunto de instru-ções executáveis no domínio de proteção de kernel. Uma vezque o acionador é instalado nesse espaço de endereço, o ker-nel convencional não pode impedir a extensão carregada deacessar qualquer hardware (ou todos) no sistema de computa-ção. Conseqüentemente, uma extensão mal formada ou maliciosapode provocar uma grande confusão em um kernel de OS.

Um acionador de dispositivo é um tipo de extensãoencontrada em sistemas operacionais, ele é um módulo desoftware que estende o sistema operacional para acessar um dispositivo específico ou classe de dispositivos. Por exem-plo, um acionador de IDE, permite que o sistema operacionalacesse unidades de disco conectadas a um controlador de ar-mazenamento IDE. Os acionadores de dispositivos executam umafunção vital, abstrair funcionalidade comum entendida pelos sistemas operacionais ou aplicações - tal como blocos deleitura e escrita de armazenadores de disco - dos mecanismosde fala de hardware específico - tal como um controlador dearmazenador de fabricante específico. Enquanto os acionado-res de dispositivo freqüentemente acessam dispositivos físi- cos, os versados na técnica reconhecerão que os acionadoresde dispositivos também podem fornecer acesso a recursos vir-tuais ou podem estar em camadas para adicionar funcionalida-de adicional - tal como um acionador de compressão que estálocalizado em cima de um acionador de dispositivo do contro-lador de armazenamento.

A complexidade de acionadores de dispositivos temcrescido consideravelmente na última década à medida que osusuários têm esperado ricas características, tal como trocaa quente e gerenciamento de energia. Muitos sistemas opera-cionais convencionais têm respondido de uma variedade deformas, mas em seus núcleos esses sistemas possuem o mesmomodelo de acionador que eles possuíam uma década atrás.

Como a extensão, um sistema operacional ("OS")convencional carrega acionadores de dispositivos carregandoinstruções executáveis no domínio de proteção do kernel. Umavez que o acionador está instalado nesse espaço de endereço,o kernel convencional não pode impedir o acionador carregadode acessar qualquer hardware (ou todos) no sistema de compu-tação .

Além disso, à medida que esses acionadores são ti-picamente escritos com primitivas de baixo nível para aces-sar hardware diretamente, o kernel convencional raramenteverifica que os acionadores usam somente recursos de hardwa-re apropriados. Ao invés, o kernel convencional confia que oacionador somente acessará hardware para o dispositivo queele reivindica servir. Além disso, freqüentemente o kernelconvencional não pode garantir que o acionador seja configu-rado corretamente, que o acionador respeitará a memória queestá alocada para processos ativos, ou até a memória alocadapara outros componentes no kernel convencional.

Conseqüentemente, os acionadores convencionais es-tão entre os componentes mais não confiáveis no OS. Algunsrelatórios indicam que 85% das falhas diagnosticadas no OSconvencional mais popular são causadas pelos acionadores.Outros relatórios indicam que os acionadores para um OS con-vencional menos popular são sete vezes mais prováveis deconter erros do que outras instruções executáveis no kernel.

Sumário da Invenção

Descritas aqui estão uma ou mais implementaçõespara descrever e/ou abordar as exigências de configuração deaplicações, extensões, acionadores de dispositivo, e outroscomponentes de um sistema de software.

Este sumário é fornecido para introduzir uma sele-ção de conceitos de uma forma simplificada, os quais são a-dicionalmente descritos abaixo na Descrição Detalhada. Estesumário não pretende identificar características chave ouessenciais do assunto reivindicado, nem pretende ser usadocomo um auxílio na determinação do escopo do assunto reivin-dicado .

Breve Descrição dos Desenhos

Os mesmos números são usados por todos os desenhospara relacionar elementos e características similares.

A Fig. 1 é um cenário operacional para uma arqui-tetura de sistema operacional que suporta uma ou mais imple-mentações descritas aqui.

A Fig. 2 é um diagrama de bloco de uma arquiteturade sistema operacional que suporta uma ou mais implementa-ções descritas aqui.

A Fig. 3 é um diagrama de bloco dos objetos em umprocesso de acionador de dispositivo e sua relação com ou-tras partes da arquitetura de sistema operacional mostradana Fig. 2.

A Fig. 4 é um fluxograma de uma outra implementa-ção metodológica descrita aqui.Descrição Detalhada da Invenção

A seguinte descrição apresenta técnicas para des-crever e/ou abordar as exigências de configuração de aplica-ções, extensões, acionadores de dispositivos, e outros com-ponentes de um sistema de software.

As extensões convencionais (por exemplo, acionado-res de dispositivos) incluem instruções executáveis para a-cesso direto a recursos de computação, tal Omo entrada/saida(1/0), memória, video, som, linhas de solicitação de inter-rupção (IRQ), ou outros hardwares. Diferente das extensõesconvencionais, as extensões (por exemplo, acionadores dedispositivos), criadas de acordo com uma ou mais implementa-ções descritas aqui, acessam recursos de computação via umou mais objetos de acesso local, que são objetos (isto é,instruções executáveis com uma ou mais estruturas de dados)que fornecem uma porta de comunicação ou ponte para os re-cursos de computação.

Com uma ou mais implementações descritas, as ex-tensões contêm metadados embutidos que especificam suas exi-gências de configuração e incluem sua necessidade por essesrecursos. O sistema operacional (OS) determina as necessida-des de recurso de computação da extensão baseado em seus me-tadados. O OS fornece as instruções executáveis necessárias(na forma dos objetos de acesso local) para alocar os recur-sos exigidos e conectar a extensão aos recursos de computa-ção fora de seu processo.

Essa nova divisão de função fornece o hospedeiroda extensão (o OS em uma ou mais modalidades para acionado-res de dispositivos) com a capacidade de verificar todas asexigências de configuração e controlar todo o acesso pelaextensão a recursos de I/O ou IPC.

Processos de Software Isolados

No âmbito da ciência de computador e, mais parti-cularmente, a técnica de sistemas operacionais, o termo"processo de software" (ou simplesmente, "processo") é bemconhecido. As aplicações são freqüentemente compostas de umou mais processos. O sistema operacional (OS) está cientedisso e, de fato, pode gerenciar e supervisionar um ou maisprocessos separados executando em um computador.

Aqui, um processo contém instruções executáveis.Um módulo de programa também contém instruções executáveis.Um ou mais processos podem executar baseados em um módulo deprograma.

Aqui, uma extensão pode ser descrita como um módu-lo de programa. Além disso, um acionador de dispositivo é umexemplo de uma extensão. Uma ou mais modalidades descritasaqui podem ser implementadas via um processo isolado. 0 con-texto de um processo isolado é descrito no contexto da Fig.1.

Uma ou mais implementações são descritas aqui paraoperar em um modelo de OS que forneça e/ou suporte configu-ração de um modelo de abstração de Processo de Software Iso-lado (SIP). Os SIPs encapsulam partes de um programa ou umsistema e fornecem ocultação de informação, isolamento defalhas, e interfaces fortes. Os SIPs são usados por todo osistema operacional e software de aplicação.A Fig. 1 mostra um cenário operacional para aconstrução de SIPs. Ela mostra uma arquitetura de construçãode processo 100 como parte de um sistema operacional 110 ar-mazenado e/ou executando em um computador 120. A arquiteturade construção de processo 100 pode ser, como mostrada naFig. 1, parte do sistema operacional. Alternativamente, todaou parte da arquitetura de construção de processo 100 podeser separada do sistema operacional, mas ainda trabalhandoem cooperação com o sistema operacional.

A arquitetura de construção de processo 100 cons-trói processos em uma memória de trabalho do computador apartir de um conjunto dinâmico de componentes constituinteseditados por um conjunto de componentes de extensão. Uma vezconstruídas, as instruções executáveis de um processo ativosão fixadas. Uma vez fixado, um processo ativo não executausualmente novas instruções executáveis por processador. Demodo a fazer isso, o processo é tipicamente novamente re-construído com as novas instruções executáveis como partedele, ou um novo processo complementar é criado.

O conjunto dinâmico de componentes constituintes ede extensão é tipicamente manifestado como um conjunto demódulos de carga armazenados no armazenador do computador. Aarquitetura de construção de processo 100 constrói processosde uma maneira que permite que análises considerando uma oumais propriedades de processos (por exemplo, integridade,segurança, confiabilidade, disponibilidade, análise de usode recursos, análise de término, e/ou estabilidade) sejamexecutadas, bem como para várias otimizações desejáveis aserem executadas.

O computador 120 inclui um dispositivo de armaze-namento em computador 122 (por exemplo, disco rígido, siste-ma RAID, etc.) que armazena um conjunto de módulos de carga124 e uma memória de trabalho 130. No exemplo da Fig. 1, aarquitetura de construção de processo 100 constrói um pro-cesso 140 que é armazenado na memória de trabalho 130. Comorepresentado aqui, o processo 140 é construído dos módulosde carga 124, que são manifestações dos componentes consti-tuintes do processo editados pelos componentes de extensãodo processo.

O processo 140 tem um manifesto de processo 142,que define os conteúdos atualizados do processo 140. Partedesses conteúdos atualizados inclui os componentes constitu-intes do processo editados pelos componentes de extensão doprocesso. Como representado aqui, o manifesto de processo142 está diretamente associado com um processo (tal como oprocesso 140) cuja composição ele descreve.

Ao construir um processo, a arquitetura de cons-trução de processo 100 pode empregar um ou mais dos seguin-tes componentes funcionais: um compositor de manifesto deprocesso 150, um criador de representação de código tipado152, um atualizador de representação de código tipado 154,um otimizador 156, um conversor de representação de códigotipado 158, um eliminador de interferência interprocessos160, e um criador de identidade fixa 162. Enquanto a Fig. 1mostra esses componentes funcionais como separados uns dosoutros, a funcionalidade de um ou mais desses componentesfuncionais pode ser combinada.

0 pedido "As Comunicações Interprocessos Empregan-do Canais de Mensagem Bidirecionais" descreve os componentesde um modelo de OS que suporta comunicações interprocessosque pode ser usada entre SIPs (e o OS também).

Com os SIPs, todas as instruções executáveis forado kernel executam em um SIP e se comunicam com outros SIPsatravés de canais de comunicação fortemente tipados. Um SIPé um ambiente fechado, que não permite compartilhamento dedados ou carregamento de código dinâmico. Os SIPs diferemdos processos de OS convencional em um número de formas.

Um novo kernel (que suporta implementações descri-tas aqui e que é representado pelo sistema operacional 210)consistem quase inteiramente de instruções executáveis segu-ras e o resto do sistema, que executa em SIPs, consiste deinstruções executáveis verificavelmente seguras, incluindoacionadores de dispositivos, processos de sistema, e aplica-ções. Enquanto todas as instruções executáveis não confiá-veis devem ser verificavelmente seguras, partes do novo ker-nel e sistema de tempo de execução, chamado a base confiá-vel, não são verificavelmente seguros. A segurança de lin-guagem protege essa base confiável de instruções executáveisnão confiáveis. Além disso, a integridade de cada SIP depen-de da segurança da instrução e de uma invariante de sistemaamplo que um processo não mantém uma referência em um outroespaço de objeto do processo.

Comunicação Interprocessos

Em pelo menos uma implementação descrita, os SIPsse comunicam exclusivamente enviando mensagens por canais.Um canal é bidirecional, conexão comportadamente tipada en-tre dois processos. As mensagens são coleções rotuladas devalores ou blocos de mensagens na Pilha de Troca que sãotransferidas a partir de um envio a um processo de recebi-mento. Um canal é tipado por um contrato, que especifica oformato das mensagens e as seqüências de mensagens válidasao longo do canal.

Um SIP cria um canal invocando um método de NovoCanal estático do contrato que retorna os dois pontos finaisdo canal - assimetricamente tipados como um exportador e im-portador - em seus parâmetros de saida.

O SIP pode passar qualquer um ou ambos os pontosfinais a outros processos pelos canais existentes. O proces-so que recebe um ponto final tem um canal ao processo man-tendo o outro ponto final correspondente. Por exemplo, se umprocesso de aplicação deseja se comunicar com um serviço desistema, a aplicação cria dois pontos finais e envia uma so-licitação contendo um ponto final ao servidor de nome doservidor, que encaminha o ponto final ao serviço, desse modoestabelecendo um canal entre o processo e o serviço.

Um canal de envio é assincrono. Um recebimentobloqueia de forma assincrona até que uma mensagem especificachegue. Usando características de linguagem, um processo po-de esperar pelo primeiro de um conjunto de mensagem ao longode um canal ou pode esperar por conjuntos específicos demensagens de diferentes canais. Quando os dados são enviadospor um canal, a propriedade passa do processo de envio, quenão pode reter uma referência à mensagem, ao processo de re-cebimento. Essa propriedade invariante é reforçada pela lin-guagem e os sistemas de tempo de execução, e serve para trêspropósitos. O primeiro é impedir compartilhamento entre pro-cessos. O segundo é facilitar análise de programa estáticaeliminando serrilhado de ponteiro de mensagens. O terceiro épermitir flexibilidade de implementação fornecendo semânti-cas de passagem de mensagem que podem ser implementadas porcópia ou passando ponteiro.

Extensibilidade Isolada

Os criadores de software raramente antecipam afuncionalidade completa demandada por usuários de seu siste-ma ou aplicação. Ao invés de tentar satisfazer qualquer umcom um sistema monolítico, a maior parte dos softwares nãotriviais fornece mecanismos para aumentar sua funcionalidadecarregando instruções executáveis adicionais. Por exemplo,alguns sistemas operacionais de computador pessoal disponí-veis comercialmente suportam mais de 100.000 acionadores dedispositivos terceiros, que habilitam um OS a controlar qua-se qualquer dispositivo de hardware. Similarmente, incontá-veis complementos e extensões de navegador de Internet au-mentam uma interface do navegador e componentes para páginasda rede. Até projetos de fonte aberta - embora potencialmen-te modificáveis - fornecem mecanismos "conectáveis", já queas extensões são mais fáceis de desenvolver e distribuir doque novas versões de software.

Uma extensão usualmente consiste de instruções e-xecutáveis que são dinamicamente carregadas no espaço de en-dereço do pai da extensão. Com acesso direto às interfacesinternas do pai e às estruturas de dados, as extensões podemfornecer rica funcionalidade. Entretanto, essa flexibilidadevem a um alto custo. As extensões são uma causa principal deproblemas com confiabilidade de software, segurança, e re-trocompatibilidade. Embora as instruções executáveis desoftware sejam freqüentemente não confiáveis, não verifica-das, sujeitas a falhas, ou até maliciosas, elas são carrega-das diretamente em um espaço de endereço do programa sem in-terface rígida, limite, ou distinção entre hospedeiro e ex-tensão .

As extensões são freqüentemente a fonte de incom-patibilidade, pobre funcionalidade, ou outros erros. Alémdisso, como uma extensão carece de uma interface rígida, elase torna dependente em detalhes da implementação de seu pai,que restringe a evolução de futuras versões de um programa eexige teste extensivo para evitar incompatibilidades.

O carregamento dinâmico de instruções executáveisimpõe uma segunda taxa menos óbvia em desempenho e correção.Um sistema que pode dinamicamente carregar instruções execu-táveis é um ambiente aberto no qual é difícil ou impossívelfazer hipóteses fundadas sobre os estados do sistema, inva-riantes, ou transições válidas. Considerando-se uma máquinavirtual Java™ (JVM), na qual, a qualquer hora, uma inter-rupção, exceção, ou troca de processo pode executar instru-ções que carregam um novo arquivo, ignoram classe e corposde método, e modificam o estado global. Em geral, não háforma possível de analisar um programa executando em tal am-biente, exceto sob a hipótese infundada de que o ambientenão muda arbitrariamente entre duas instruções executáveis.

A nova aproximação empregada por uma ou mais im-plementações descritas aqui é proibir carregamento dinâmicode instruções executáveis e isolar uma extensão dinamicamen-te criada em seu próprio ambiente. Tentativas anteriores aolongo dessas linhas não foram amplamente usadas porque osmecanismos de isolamento tinham problemas de desempenho eprogramabilidade que os tornavam menos atrativos do que osriscos de executar sem isolamento.

O mecanismo de isolamento mais predominante é umprocesso de OS tradicional, mas seus altos custos limitamsua usabilidade. Hardware de gerenciamento de memória ouprocessadores modernos fornecem um processo com limites rí-gidos e protegem estado do processador, mas impõem uma altapenalidade no controle interprocessos e transferências dedados. Em processadores x86 modernos, a troca entre proces-sos pode custar de centenas a milhares de ciclos, não inclu-indo perdas de recarga de cache e TLB.

Sistemas mais recentes, tal como a máquina virtualJava™ (JVM) e o Tempo de Execução de Linguagem Comum (CLR)da Microsoft®, são projetados para extensibilidade e conse-qüentemente usam segurança de linguagem, não hardware, comoo mecanismo para isolar computações executando em um mesmoespaço de endereço. Entretanto, linguagens seguras, por elasmesmas, podem ser uma garantia insuficiente de isolamento.Dados compartilhados fornecem um caminho entre os espaços deobjeto das computações, nos quais APIs de reflexão pontualfornecem um mecanismo para subverter abstração de dados eocultação de informação. Como uma conseqüência, esses siste-mas exigem políticas e mecanismos de segurança complexos,tal como controle de acesso fino JVM ou a Segurança de Aces-so a Código do CLR, para controlar acesso a mecanismos e in-terfaces de sistema.

Em adição, as computações que compartilham um sis-tema de tempo de execução e executam em um mesmo processonão são isoladas mediante falha. Quando uma computação exe-cutando em uma JVM falha, o processo JVM inteiro tipicamenteé reiniciado porque é difícil isolar e descartar dados cor-rompidos e encontrar um ponto limpo para reiniciar a compu-tação que falhou.

Pelo menos uma implementação descrita aqui empregaSIPs para encapsular instruções executáveis de componentesde sistema em um ambiente fechado. As extensões para o sis-tema ou uma aplicação executam em um novo SIP e se comunicamcom um pai pelos canais que fornecem funcionalidade apropri-ada e limitada. Se a extensão falha, seu SIP termina, quepermite que o OS exija recursos e notifique os parceiros decomunicação. Como esses parceiros não compartilham estadocom a extensão, a recuperação de erro é local e é facilitadapelos protocolos explícitos dos canais.

Uma ou mais implementações descritas aqui fornecemreflexão de tempo de compilação (CTR), que fornece funciona-lidade que executa quando um arquivo é compilado para gerarnovas instruções executáveis. A reflexão normal, que executano tempo de execução, tem acesso aos valores de tempo de e-xecução e é mais geral do que CTR. Entretanto, em muitos ca-sos, as novas instruções executáveis desejadas são conheci-das à frente de execução. Nesses casos, CTR produz novasinstruções executáveis durante a compilação.

Arquitetura de Computador Suportando Configuraçãode Acionadores de Dispositivos Isolados

Alguns acionadores de dispositivos convencionaissão carregados no espaço de endereço do kernel e no domíniode proteção de hardware sem mecanismos para isolar as ins-truções executáveis do acionador das instruções executáveisdo kernel. Entretanto, uma ou mais implementações descritasdescreveram um sistema operacional que suporta acionadoresde dispositivos isolados.

A Fig. 2 representa uma arquitetura de sistema o-peracional (OS) exemplificada 200 que suporta configuraçãode extensões e acionadores de dispositivos isolados e uma oumais implementações descritas aqui. Como representado, a ar-quitetura de OS exemplificada 200 mostra um kernel 210, umou mais acionadores de dispositivos 220, um ou mais sistemasde arquivos 230, e uma ou mais aplicações 240. Os versadosna técnica reconhecerão que o OS pode incluir serviços de OSadicionais que executam nos SIPs "como o sistema de arquivos330.

O kernel 210 é um componente de sistema privilegi-ado que controla o acesso a recursos de hardware, aloca erecupera memória, cria e programa processos, fornece sincro-nização intraprocesso, e gerencia 1/0.

O kernel 210 fornece a funcionalidade de núcleo doOS. Isso inclui, por exemplo, gerenciamento de memória e ou-tros recursos de hardware, criação e término de processo,comunicações interprocessos, operações de canal, programa-ção, e 1/0. Alguns dos componentes desse kernel 210 incluemum gerenciador de 1/0 211, programador 212, gerenciador depágina 213, coordenador de acionador de dispositivo 214, ecamada de abstração de hardware (HAL) 215.

As instruções executáveis nessa arquitetura de OSexemplificada 200 são ou verificadas ou confiáveis. A segu-rança de tipo e a segurança de memória das instruções veri-ficadas são verificadas por um compilador. As instruções nãoverificáveis devem ser confiáveis pelo OS e são limitadas àHAL 215, ao kernel 210, e partes dos tempos de execução con-fiáveis 324, 334 e 344. A maior parte do kernel é verifica-damente segura.

Todas as instruções executáveis fora do kernel edo tempo de execução confiável são escritas em uma linguagemsegura, tal como C# ou Java, traduzida para uma linguagemintermediária segura, tal como a Linguagem Intermediária daMicrosoft® (MSIL), e então compilada para instrução executá-vel de processador por um ou mais outros compiladores auxi-liares.

A linha de divisão entre as instruções de kernel eas instruções de SIP é indistinta pelo sistema de tempo deexecução confiável. O tempo de execução confiável contéminstruções executáveis não verificáveis. A instrução execu-tável do tempo de execução é protegida das instruções doSIP, porque sua segurança de tipo verificada impede-as deinteragir com o sistema de tempo de execução e com suas es-truturas de dados exceto através de interfaces seguras. Emmuitos casos, o compilador auxiliar pode seguramente escalo-nar instruções do tempo de execução confiável na instruçãoexecutável do SIP, desse modo seguramente movendo operaçõesque tradicionalmente executariam em um kernel em um processode usuário.

As instruções executáveis do acionador de disposi-tivo 220 incluem instruções escritas pelo programador do a-cionador de dispositivo mais as instruções executáveis deuma ou mais bibliotecas de classes 222 e seu tempo de execu-ção confiável 224. Similarmente, como representado, o siste-ma de arquivos 230 inclui instruções executáveis de biblio-tecas de classes 232 e seu tempo de execução confiável 234.Além disso, como representado, a aplicação 240 inclui ins-truções executáveis de bibliotecas de classes 242 e seu tem-po de execução confiável 244.

A Fig. 3 representa os objetos relacionados à con-figuração em um processo de acionador de dispositivo exem-plificado 300 e sua relação com outras partes de uma arqui-tetura de sistema operacional (OS) exemplificada 200 supor-tada por uma ou mais implementações descritas aqui. Como re-presentado, a arquitetura de OS exemplificada 200 mostra umkernel de OS 310, um processo de acionador de dispositivoexemplificado 300, e recursos de hardware e outros recursosde computação 350.

O kernel de OS 310 inclui um ou mais canais 312para habilitar passagem de mensagem interprocessos. Como re-presentado, os recursos de hardware e outros recursos decomputação 350 incluem uma porta I/O 352 (também conhecidacomo um registrador I/O), memória I/O 354, um controladorDMA 356, e uma linha de solicitação de interrupção (IRQ)358. É claro, esses são somente exemplos de alguns recursosde hardware e outros recursos de computação. Outras imple-mentações podem incluir outros recursos de hardware e outrosrecursos de computação comuns e incomuns. As implementaçõespodem também incluir mais do que uma porta I/O 352, memória1/0 354, controlador DMA 356, ou linha de solicitação de in-terrupção (IRQ) 358. Alguma implementação pode não incluirtodos esses tipos de recursos de hardware.

O processo de acionador de dispositivo exemplifi-cado 300 contém objetos implementando as funções do aciona-dor de dispositivo, objetos de acionador de dispositivo 326.O processo de acionador de dispositivo 300 também contém umtempo de execução confiável 224, zero ou mais bibliotecas declasses 222, e um objeto de configuração 328.

Os objetos de acionador de dispositivo 326 incluemum exemplo de um módulo de programa não confiável. Diferentedas aproximações convencionais, ao código executável do a-cionador de dispositivo não é dado livre domínio. Entretan-to, suas ações não são também fiscalizadas ou verificadas.Ao invés, com uma ou mais implementações descritas aqui, aoacionador de dispositivo não confiável é dado livre, mas in-direto acesso a um conjunto limitado de recursos de computa-ção .

O tempo de execução confiável 224 inclui objetosde acesso que mediam acesso a recursos de hardware e IPC.Esses objetos de acesso incluem (a titulo de exemplo e nãolimitação) IoPort 332, IoMemory 334, IoDma 336, IoIrq 338, eponto final 340. Os objetos de acesso no tempo de execuçãoconfiável 224 agem como portas de comunicação para os se-guintes recursos:

- IoPort 332 -> Porta 1/0 352;

- IoMemory 334 -> Memória 354;

- IoDma 336 -> Canal DMA 356;

- IoIrq 338 -> Linha IRQ 358;

- Pontos finais 340 -> Manipulador de Canal 312.

Diferente dos acionadores de dispositivo conven-cionais, os arquivos contendo as instruções executáveis dosobjetos de acionador de dispositivo 326 não incluem instru-ções executáveis para configurar o acionador de dispositivoou para diretamente acessar hardware e outros recursos decomputação, tal como aqueles representados em 350. Ao invés,a instrução executável nos objetos de acionador de disposi-tivo 326 somente acessa recursos de hardware e outros recur-sos de computação via objetos de acesso 332, 334, 336, 338,e 340, cujas instruções executáveis estão contidas no tempode execução confiável 224.

As instruções executáveis para criar o objeto deconfiguração 328 e para acessar objetos 332, 334, 336, 338 e340 não estão incluídas nos arquivos fornecidos pelo progra-mador do acionador de dispositivo. Ao invés, o programadorde acionador de dispositivo embute exigências de configura-ção como metadados anexados às instruções executáveis para oacionador de dispositivo. Com uma ou mais implementaçõesdescritas, as instruções executáveis para criar o objeto deconfiguração 328 e acessar os objetos 332, 334, 336, 338 e340 são separadas e configuradas à parte das instruções exe-cutáveis do resto dos objetos do acionador de dispositivos.

Em uma ou mais implementações, as instruções exe-cutáveis para criar o objeto de configuração 328 são forne-cidas pelo sistema operacional. Em uma implementação, essasinstruções executáveis são geradas no tempo de instalaçãousando modelos de reflexão de tempo de compilação (CTR). Osmodelos CTR processam as exigências de configuração embuti-das como metadados na descrição do objeto de configuraçãocodificado no acionador de dispositivo. Em uma outra imple-mentação, os modelos CTR processam um manifesto, partes doqual foram criadas a partir dos metadados de configuraçãonos arquivos contendo as instruções executáveis para os ob-jetos de acionador de dispositivo 326. Em uma outra imple-mentação, as instruções executáveis no tempo de execuçãoconfiável 224 criam o objeto de configuração interpretandoou os metadados de configuração ou o manifesto de acionadorde dispositivo.

A arquitetura OS exemplificada 200 executa cadaacionador de dispositivo (tal como o acionador 200) em umprocesso de software isolado (SIP) separado. A arquiteturade OS exemplificada 200 usa segurança de linguagem para ve-rificar que nenhum SIP é capaz de escrevem em outras páginasdo SIP. Encapsulados nos SIPs, acionadores individuais podemser parados e reiniciados à medida que necessário sem dani-ficar o sistema operacional inteiro.

Programas para a arquitetura de OS exemplificada200 são estaticamente ligados no tempo de instalação a umtempo de execução confiável. Enquanto programas são estati-camente verificados para segurança de tipo, cada tempo deexecução confiável é um componente de sua base de computaçãoconfiável do sistema (TCB). As instruções executáveis notempo de execução confiável mantêm isolamento de processo,permitindo que os processos executem no modo privilegia-do/supervisor do processador hospedeiro sem ser capaz de a-fetar a memória e recursos de hardware de outros processos.Em uma implementação descrita, a reflexão dinâmica ou outrosmecanismos que podem contornar a segurança de tipo não sãopermitidos em instruções executáveis fornecidas pelo progra-mador do acionador de dispositivo.

0 tempo de execução confiável para acionadores dedispositivo fornece um ambiente seguro que abstrai comunica-ção com hardware. As instruções executáveis por processadorpara manipular solicitações de interrupção, acessar memóriafixa, acessar portas I/O (também conhecidas como registrado-res 1/0), e controlar controladores de acesso direto à memó-ria (DiVlA) são protegidas através de objetos de acesso expos-tos pelo tempo de execução de acionador.

Toda a comunicação interprocessos (IPC) é atravésde canais bidirecionais fortemente tipados. Esses canais têmexatamente dois pontos finais. As mensagens em um canal sãorestritas a tipos de valores, e o formato dessas mensagens édefinido por um contrato. O contrato também serve como umprotocolo de canal que especifica seqüências válidas de men-sagens enviadas através do canal, e inclui uma etapa de "a-perto de mão" para iniciar comunicação. Uma adaptação da a-plicação ao contrato pode ser estaticamente verificada.

Alguns pontos finais têm um nome público de modo apermitir fácil conexão por clientes. Isso é alcançado atra-vés de um único espaço de nome globalmente acessível enrai-zado. Um servidor de espaço de nomes global gerencia o espa-ço de nome, e permite o mapeamento de nomes a pontos finaisde canal, diretórios, e ligações simbólicas. O espaço de no-me não é conectado a um armazenamento complementar persis-tente. Ao invés, a política do sistema permite que algumasaplicações (tal como o sistema de arquivo) criem sub-árvoresvirtuais no espaço de nome e mapeiem conteúdo nessas árvo-res. Isso permite o equivalente de um sistema de arquivosconvencional, com a distinção de que o acesso aos arquivos éatravés da abstração de canal.

A arquitetura de OS exemplificada 200 tem uma abs-tração para tratar aplicações (tal como 240) como entidadesde primeira classe, que habilita que o sistema operacionalconsidere sobre aplicações e forneça garantias. Os acionado-res de dispositivos são uma sub-classe dessa abstração. Alémdisso, a instalação do acionador de dispositivo é uma opera-ção de primeira classe executada pelo OS nas aplicações.

Na arquitetura de OS exemplificada 200, o aciona-dor de dispositivo declara suas exigências de configuraçãode 1/0 e IPC. Em aproximações convencionais, as exigênciasde configuração são impossíveis de serem descobertas. Aqui,as exigências de configuração são codificadas no mesmo ar-quivo das instruções executáveis do acionador de dispositi-vo. As exigências de configuração codificadas podem ser con-vertidas, para processamento mais fácil, em uma especifica- ção autônoma que declara as exigências de configuração.

As exigências de configuração são verificáveis nahora da compilação, na hora da instalação, na hora da reini-cialização, e na hora da execução. De fato, a codificação deexigências de configuração no mesmo arquivo à medida que o acionador de dispositivo as transforma em um artefato auto-descritivel. Dado o conjunto de conjuntos MSIL para o acio-nador de dispositivo, o OS pode considerar completamente so-bre as pré-condições de configuração (e as dependências deambos recursos de software e de hardware) que devem ser al- cançadas de modo ao acionador de dispositivo funcionar cor-retamente.

Com a abstração de aplicação e as declarações deconfiguração de acionador, a arquitetura de OS exemplificada200 pode fornecer garantias sobre os recursos de 1/0 e IPC usados por um acionador de dispositivo. Por exemplo, o OSpode detectar conflitos de configuração antes do acionadorexecutar comparando o conjunto de recursos desejados por umnovo acionador de dispositivo com o conjunto de recursos u-sados por todos os outros acionadores de dispositivo e veri-ficando recursos sobrepostos - e, portanto, conflito - talcomo faixas de porta 1/0 ou de memória 1/0. Em uma modalida-de preferencial, os conflitos de configuração são detectadosna hora da instalação, e a instalação é permitida somente senão houver conflitos entre o novo acionador de dispositivo eo resto do sistema, incluindo todos os acionadores de dispo-sitivo previamente instalados.

Como um outro exemplo, o OS pode criar uma ordemde reinicialização total válida - a ordem na qual os aciona-dores de dispositivo são inicializados - extraindo uns dosoutros suas dependências de configuração, então classifican-do a lista tal que nenhum acionador de dispositivo seja ini-cializado antes de uma de suas dependências. A criação auto-mática de uma ordem de reinicialização de sistema total vá-lida é um avanço significativo sobre sistemas anteriores on-de uma ordem de reinicialização está ou codificada permanen-temente no OS na hora do desenvolvimento ou é manualmenteatualizada por um administrador. Como um exemplo final dasgarantias derivadas das exigências de configuração declara-tivas, o OS é capaz de gerar toda instrução executável parainicialização do acionador relacionada à configuração do a-cionador e aquisição de recursos. Como tal, o OS pode garan-tir que os acionadores somente usem recursos declarados eesses recursos são adquiridos seguindo políticas de sistema.Essas capacidades aumentam a confiabilidade e sustentabili-dade do sistema sem custo significativo em desempenho detempo de execução.

Coordenação de Acionador de Dispositivo

Diferente de aproximações convencionais, o coorde-nador de acionador de dispositivo 214 de uma ou mais imple-mentações descritas aqui impede que um acionador acesse lo-calizações de memória ou outros recursos de hardware inapro-priados. De forma oposta, o coordenador de acionador de dis-positivo permite que um acionador acesse somente localiza-ções de memória e outros recursos de hardware apropriados.Além disso, ao invés de um acionador diretamente acessarhardware e recursos (que é o que as aproximações convencio-nais permitem), o kernel 210 veta um acesso do acionador ahardware e recursos.

Uma ou mais implementações descritas aqui têm umsistema de entrada/saida (I/O) consistindo de três camadas:HAL 214, gerenciador de I/O 211, e acionadores 220. A HAL214 é uma pequena base de instruções executáveis confiáveisque abstrai acesso a hardware do computador. Por exemplo, emuma modalidade, a HAL implementou quatro objetos de acessopara manipular hardware: o objeto IoPort 332 para acessaruma porta I/O 352 (também conhecida como um registradorI/O), o objeto IoMemory 334 para acessar a memória I/O 354,o objeto IoDma 336 para acessar um controlador DMA 356, e oobjeto IoIrq 338 para acessar uma linha de solicitação deinterrupção 358. Em uma modalidade, a HAL 314 também incluiinstrução executável para o controlador de tempo, controla-dor de interrupção, e hardware de relógio em tempo real. Ogerenciador de I/O 211 é responsável por inicializar os a-cionadores de dispositivo e conectar as aplicações aos acio-nadores de dispositivo 220.

O kernel 210 usa ou os metadados de configuraçãode acionador de dispositivo 220 diretamente, ou manifestospara cada acionador de dispositivo (por exemplo, manifestode processo 142 representado na Fig. 1) para configurar osacionadores de dispositivo 220 e conectar os recursos neces-sários para executar corretamente. Na inicialização, o ker-nel 210 faz uma configuração conectar e ligar do sistema. Okernel 210 usa informação adquirida da BIOS pelo carregadorde reinicialização e de barramentos, tal como o barramentoPCI, para enumerar dispositivos, para iniciar os acionadoresde dispositivos apropriados, e para passar esses objetos deacionadores que encapsulam acesso ao hardware de dispositi-vo .

Cada acionador 220 é escrito em instruções execu-táveis seguras e executa em seu próprio processo. Os aciona-dores se comunicam com outras partes do sistema, incluindo apilha de rede e sistema de arquivo, exclusivamente atravésdos canais. Quando um acionador inicia, o gerenciador de I/O211 fornece - como exigido pelo manifesto do acionador dedispositivo 220 - acesso a objeto 332, 334, 336, e 338 paracomunicar com hardware de dispositivo 352, 354, 356, e 358.Todos esses objetos de acesso fornecem um a interface seguraque verifica cada referência antes de diretamente acessar aslocalizações mapeadas na memória do hardware.

Em uma modalidade usando isolamento de software,as instruções executáveis inteiras para os objetos de acesso1/0 estão contidas no tempo de execução confiável 324 e exe-cutando no processo acionador-acionador 300. As verificaçõespara garantir que o acesso a hardware é válido são executa-as por instruções executáveis nos objetos de acesso 1/0332, 334, 336, e 338 no tempo de execução confiável 224. Emuma outra modalidade usando isolamento de hardware, o hard-ware de isolamento de processo do processador é programadopara permitir que um acionador de dispositivo acesse somenteregiões especificas do espaço de porta I/0 ou espaço de me-mória I/0 ao qual o acionador foi garantido acesso. Na moda-lidade usando o isolamento de hardware, instruções executá-veis para configurar o hardware de isolamento de processoresidem no kernel de OS 210.

Configuração de Acionador

Uma ou mais implementações usam exigências de con-figuração codificadas em metadados em componentes de sistemapara descrever partes do sistema, explicar'como elas encai-xam juntas, e especificar sua interação de comportamento comoutras partes do sistema. Os metadados de forma declarativarotulam cada componente do sistema, tal como o kernel, umaaplicação, ou acionador de dispositivo, e suas exigências deconfiguração. As exigências de configuração incluem informa-ção sobre as dependências, serviços exportados, e exigênciasde recurso. As ferramentas usam esses metadados antes da e-xecução do sistema para verificar que as instruções executá-veis do componente de sistema podem ser configuradas corre-tamente. Esses metadados são usados durante a execução dosistema para configurar cada componente do sistema correta-mente tal que ele possa executar como pretendido por seuprogramador.

Os metadados de sistema são alcançados em um oumais armazenadores de sistema chamados manifestos. Um mani-festo de sistema de alto nivel aponta para manifestos des-crevendo componente individual (tal como acionadores de dis-positivo). Através desses manifestos, tal como um carregadorde reinicialização ou verificador de sistema, pode-se desco-brir cada componente do sistema.

Os manifestos do sistema são suficientes para ha-bilitar análise fora de linha do sistema. Com implementaçõesdescritas aqui, um administrador é capaz de descobrir a res-posta a muitas questões relacionadas a "acionador de dispo-sitivo" usando somente uma descrição dos dispositivos dehardware e do manifesto do sistema. Tais questões incluem,por exemplo, o sistema reiniciará no hardware particular?Quais acionadores e serviços inicializarão? E quais aplica-ções podem executar?

Especificação

Uma imagem de sistema executável contém exigênciasde configuração para o sistema inteiro embutidas como meta-dados. Usando os metadados, uma ou mais das implementaçõesdescritas mantêm três invariantes. Primeiro, o OS nunca ins-talará um acionador de dispositivo que não pode iniciar comsucesso devido às exigências de configuração que entram emconflito com um outro acionador ou uma outra parte do siste-ma. Segundo, o OS nunca iniciará um acionador de dispositivoque não pode executar com sucesso devido ou a conflitos deconfiguração ou a recursos faltando. Terceiro, um acionadorde dispositivo não pode usar recursos na hora da execuçãoque não foram declarados em suas exigências de configuração.

Quando possível, uma ou mais implementações des-critas aqui usam atributos de metadados padrão em linguagensde alto nível para intercalar exigências de configuração emcódigo fonte, tal que somente um documento fonte deva sermantido. Os atributos padrão podem ser conectados a entida-des de código fonte tal como classe, método, ou declaraçõesde campo. Um compilador codifica atributos no arquivo con-tendo as instruções executáveis de linguagem intermediária.Os compiladores, ligadores, ferramentas de instalação, eferramentas de verificação podem ler os metadados codifica-dos com as instruções executáveis mesmo que eles não estejamexecutando as instruções.

Como um exemplo, o seguinte código fonte mostraalguns atributos usados para declarar as exigências de con-figuração de um acionador de dispositivo de video (tal comoacionador de dispositivo de video s3™Trio64™) :[Signature("/pci/03/00/5333/8811")]class S3GtrioConfig : DriverCategoryDeclaration

{

// Recursos de hardware de config PCI[IoMemoryRange(0, Default = 0xf8000000, Lenght =

0x400000) ]

IoMemoryRange frameBuffer;

// Recursos de hardware fixos

[IoFixedMemoryRange(Base = 0xb8000, Lenght

0x8000)]

IoMemoryRange textBuffer;

[IoFixedMemoryRange(Base = OxaOOOO, Lenght =

0x8000)]IoMemoryRange fontBuffer;

[IoFixedPortRange(Base = 0x03c0, Lenght = 0x20)]

IoPortRange control;

[IoFixedPortRange(Base = 0x4ae8, Lenght = 0x02)]

IoPortRange advanced;

[IoFixedPortRange(Base = 0x9ae8, Lenght = 0x02)]

IoPortRange gpstart;

// canais

[ExtensionEndpoint(typeof(ExtensionContract.Exp))]

Tref<ExtensionContract.Exp:Start> iosys;

[ServiceEndpoint(typeof(VideoDeviceContract.Exp))]

Tref<ServiceProviderContract.Exp:Start> video;

}

Os atributos [DriverCategory] e [Signature] decla-ram esse módulo como sendo um acionador de dispositivo parauma classe especifica de dispositivos de video PCI. A Dri-verCategory denota uma categoria de aplicações que implemen-tam acionadores de dispositivos para hardware especifico.

Outras categorias incluem ServiceCategory, para aplicaçõesimplementando serviços de software, e WebAppCategory paraextensões de um servidor da rede.

O atributo [IoMemoryRange] declara que frameBufferé derivado da primeira entrada no espaço de configuração PCIdo dispositivo. Essa localização do armazenador temporáriode quadros é determinada quando o hardware é configurado, eos parâmetros de hardware, tal como o tamanho da região dememória, devem ser compatíveis com os valores de configura-ção no atributo. Os atributos [IoFixedMemoryRange] e [IoFi-xedPortRange] especificam que o acionador necessita ou deuma faixa fixa de espaço de endereço para acesso mapeado emmemória ou faixas fixas de portas 1/0 para acessar registra-dores de dispositivo.

Nessa modalidade, os objetos IoDmaRange, IoIrqRan-ge, IoMemoryRange, e IoPortRange são recipientes para cole-ções de objetos de acesso consecutivos e podem ser usados deforma intercambiável com objetos de acesso, IoDma, Iolrq, eIoPort respectivamente.

O atributo [ExtensionEndpoint] declara que o acio-nador deve ser configurado com um ponto final de canal parase comunicar com o processo pai do acionador. No caso de a-cionadores de dispositivo, tal como o S3™Trio64™, o sistema1/0 é o processo pai.

O atributo [ServiceEndpoint] declara que o aciona-dor deve ser configurado com um ponto final de canal para oserviço de diretório de sistema e que aplicações usando oacionador de vídeo serão limitadas ao acionador de disposi-tivo pelo serviço de diretório através desse ponto final.

Hora de Compilação

Na hora da compilação, o compilador de linguagemde alto nível embute atributos padrão como metadados no ar-quivo contendo as instruções executáveis de linguagem inter-mediária para o acionador de dispositivo. Usando uma biblio-teca de acesso a metadados de linguagem intermediária, umaou mais implementações descritas podem restaurar os metada-dos embutidos a partir do arquivo de linguagem intermediáriasem executar as instruções executáveis contidas no arquivo.

Na hora da ligação, uma ferramenta de criação demanifesto lê os metadados de atributos padrão a partir doarquivo de linguagem intermediária para criar um manifestode aplicação. Um manifesto de aplicação é um arquivo XML e-numerando os componentes e exigências de configuração da a-plicação. Os manifestos de aplicação são descritos em maisdetalhes em "Artefatos Autodescritiveis e Abstrações de A-plicação".

0 seguinte XML contém parte da informação de mani-festo para o acionador de dispositivo de video (tal como umacionador de dispositivo de video S3™Trio64™) :

<device signature = "/pci/03/00/5333/8811" /><ioMemoryRange index="0" baseAddress

"Oxf8000000"rangeLenght = "0x400000" />

<ioMemoryRange baseAddress = "0xb8000"rangeLenght = "0x8000" fixed = "True" /><ioMemoryRange baseAddress = "OxaOOOO"rangeLenght = "0x8000" fixed = "True" />CioPortRange baseAddress = "0x3c0"

rangeLenght = "0x20" fixed = "True" />CioPortRange baseAddress = "0x4ae8"rangeLenght = "0x2" fixed = "True" />CioPortRange baseAddress = "0x9ae8"rangeLenght = "0x2" fixed = "True" />

<extension startStateld = "3" contractName ="MS.OS.Extending.ExtensionContract"endpointEnd="Exp" assembly="Namespace.Contracts"/><serviceProvider startStateld = "3" contractName ="MS.OS.Io.VideoDeviceContract"

endpointEnd="Exp" assembly = "Io.Contracts" /></driverCategory>...

</manifest>

Hora de Instalação

Com uma ou mais implementações descritas aqui, osistema garante não instalar um acionador de dispositivo quenão pode iniciar. Para fazer isso, o sistema verifica que asexigências de configuração inteiras do acionador de disposi-tivo podem ser satisfeitas antes do acionador de dispositivoser instalado.

Uma aplicação é uma abstração de primeira classeem um OS suportando uma ou mais implementações descritas a-qui. Esse conceito é descrito em mais detalhes em "ArtefatosAutodescritiveis e Abstrações de Aplicação". Em uma modali-dade, de modo a serem executadas, um conjunto de instruçõesexecutáveis é adicionado à aplicação por um instalador parainicializar a aplicação de acordo com suas exigências deconfiguração. Em uma implementação alternativa, as instru-ções executáveis para inicializar a aplicação de acordo comsuas exigências de configuração estão contidas no tempo deexecução confiável e criam o objeto de configuração e obje-tos de acesso interpretando os metadados de configuração daaplicação.

O instalador inicia com os metadados no manifestoda aplicação. 0 instalador verifica se cada um dos conjuntosde aplicação existe e é seguro em memória e tipo. Ele tambémverifica se todos os contratos de canal são implementadoscorretamente.

Uma vez que essas propriedades internas são resol-vidas e verificadas, o instalador a seguir tenta resolver everificar todas as dependências externas. Por exemplo, oinstalador assegura que quaisquer recursos de hardware usa-dos por um acionador de dispositivo não conflitam com recur-sos de hardware exigidos por qualquer outro acionador. 0instalador também verifica a existência de todo tipo de ca-nal usado pela aplicação. Se a aplicação exporta um canal, oinstalador verifica que um canal exportado não conflita comuma outra aplicação. Quando os conflitos chegam, a políticano manifesto do sistema os resolve. Por exemplo, o manifestodeve declarar que somente um acionador de dispositivo podefornecer o contrato de console de vídeo. A instalação de a-cionadores de vídeo adicionais pode ser desabilitada, ou so-mente um único acionador de vídeo ativado na hora da reini-cialização.

A reflexão de Tempo de Compilação (CTR) é usadapara gerar instrução executável confiável para inicializar oobjeto de configuração da aplicação e objetos de acesso pararecursos de sistema. Em uma modalidade, os modelos CTR exe-cutam na hora da instalação processando os elementos de pro-grama atribuídos nos conjuntos chamados pelo manifesto deaplicação.

O processo de instalação é completado atualizandoos metadados de manifesto do sistema para incorporar a novaaplicação ou acionador de dispositivo.

Em pelo menos uma implementação, o processo deinstalação inteiro acontece fora de linha com uma instalação se tornando visível somente na próxima reinicialização dosistema. Alternativamente, o processo de instalação inteiropode ser executado em linha e/ou parcialmente em linha.

Hora de Execução

Na hora da execução, os metadados acionam a inici- alização do kernel, acionadores de dispositivo, serviços eaplicações. O carregador de reinicialização lê uma parte domanifesto do sistema para determinar qual kernel, acionado-res de dispositivo, e serviços deveriam ser carregados. Aordem na qual esses carregam e iniciam a executar não é es- pecificada em nenhum lugar; ao invés, o sistema a conclui apartir das dependências especificadas.

À medida que cada aplicação é iniciada, o kernelverifica e resolve todas as dependências de metadados econstrói um registro de configuração de processo no kernel. Instruções executáveis confiáveis, emitidas na aplicação u-sando CTR, analisa o registro de configuração para criar oobjeto de configuração 328 e para criar objetos de acesso332, 334, 336, 338, 340 para acessar recursos externos. Areflexão de tempo de compilação (CTR) gera as instruções e- xecutáveis para o objeto de configuração 428.

Voltando ao exemplo do acionador de dispositivoS3™Trio64™, o kernel registra no registro de configuraçãodo acionador a necessidade por objetos IoMemoryRange paraframeBuffer, textBuffer, e fontBuffer. O kernel também re-gistra os objetos IoPortRange para controle, avançado, eportas I/O gpstat. O kernel cria um canal para conectar oacionador de dispositivo ao sub-sistema I/O e um segundo ca-nal para conectar o acionador ao espaço de nomes. Os pontosfinais do canal são adicionados ao registro de configuraçãodo acionador.

Quando o acionador de dispositivo começa a execu-tar, as instruções executáveis no tempo de execução confiá-vel criam os objetos de acesso apropriados IoMemoryRange eIoPortRange no espaço de objeto do acionador. Como esses po-dem ser construídos somente pelo tempo de execução confiá-vel, um acionador de dispositivo pode somente acessar recur-sos I/O declarados em seus metadados de configuração e veri-ficados por conflitos pelo sub-sistema I/O de kernel.

Declarar pontos finais de canal em metadados deconfiguração assegura três propriedades. Primeiro, as ins-truções executáveis para um SIP podem ser estaticamente ve-rificadas para assegurar que elas se comuniquem somente a-través de canais completamente declarados, em adequação res-trita aos contratos de canal. Segundo, as aplicações não ne-cessitam conter nomes globais. Por exemplo, o acionador dedispositivo de vídeo S3™Trio64™ não está ciente do nomedev/vídeo no espaço de nome do sistema. Ao invés, o aciona-dor usa um nome local, S3™Trio64Config.vídeo, para se refe-rir a um canal com um dado contrato (ServiceProviderCon-tract) . A diagramação inteira do espaço de nomes 1/0 podemudar sem afetar uma única linha de código fonte no aciona-dor de vídeo. Terceiro, as aplicações podem ser "caixas deareia" se adequando ao principio de privilégio menos possí-vel, para remover uma fonte de erro e vulnerabilidade de se-gurança em sistemas atuais. Por exemplo, embora o acionadorS3™Trio64™ mantenha um ponto final conectado ao serviço dediretório de sistema, o acionador não tem habilidade de cri-ar novos nomes ou de se conectar a qualquer outro processode sistema.

Implementação Metodológica dos Acionadores de Dis-positivos Isolados

A Fig. 4 mostra o método 400 para inicialização dequalquer extensão (tal como um acionador de dispositivo) .Como esse método 400, o OS lê os metadados a partir do mani-festo do acionador de dispositivo para criar objeto de acio-nador de dispositivo. Esse método 400 é executado por um oumais dos vários componentes como representado na Fig. 1. A-lém disso, esse método 400 pode ser executado em software,hardware, suporte lógico inalterável ou uma combinação des-ses .

Em 402 da Fig. 4, o sistema operacional (OS) obtémmódulo de programa não confiável (tal como um acionador dedispositivo). O OS determina um conjunto de recursos de com-putação solicitados a partir do manifesto do acionador dedispositivo. Aqui, os recursos de computação podem incluirrecursos virtuais (tal como um canal) ou recursos de hardwa-re (tal como uma faixa de Portas I/O ou memória 1/0) ou ou-tros tais recursos.

O OS pode fazer essa determinação lendo o manifes-to do acionador de dispositivo. Alternativamente, o OS podeanalisar as instruções executáveis do acionador de disposi-tivo. Alternativamente ainda, o OS pode extrair metadadosdas instruções executáveis ou uma estrutura de dados associ-ada.

Em 4 04, o OS determina se qualquer um dos recursosjá está alocado ao OS ou um outro acionador de dispositivo.Se estiver, o processo aborta em 406. Modalidades alternati-vas da invenção devem seguir o aborto com política adicio-nal, tal como reiniciar o processo de inicialização quandoos recursos foram liberados, negociar com o proprietário a-tual para liberar os recursos, perguntar ao usuário por per-missão para parar o acionador de conflito, notificar o es-critor de acionador de dispositivo de uma solicitação de re-curso potencialmente errôneo, etc.

Também, aqui, o OS pode fazer outras determinaçõesrelacionadas ao acionador de dispositivo e aos recursos decomputação solicitados. 0 OS confirma que o acionador dedispositivo é permitido a acessar esses recursos de computa-ção solicitados e acessá-los da maneira que ele solicita.

Em 408, o OS registra alocação de recursos para oacionador de dispositivo.

Em 410, o OS fornece um objeto de acesso localconfiável a ser usado pelo acionador de dispositivo para ca-da recurso exigido ou solicitado. Os objetos de tempo de e-xecução confiável (representado na Fig. 3) são exemplos deobjetos de acesso local.

0 "fornecimento" que o OS executa aqui pode inclu-ir simplesmente empregar instruções executáveis fixadas e jápré-configuradas (e dados) - que são os objetos de acessolocal. Ele pode incluir gerar novas instruções (talvez base-ado em um modelo) que são personalizadas para as necessida- des e condições particulares. Ou o OS pode fazer alguma coi-sa intermediária. Por exemplo, ele pode configurar ou leve-mente alterar instruções executáveis existentes - que são osobjetos de acesso local.

De fato, o OS pode inserir ou ligar as instruções executáveis (e dados) do objeto de acesso local confiável aoacionador de dispositivo não confiável tal que o acionadorde dispositivo possa ganhar acesso via o objeto de acessolocal ligado ou inserido.

Em 412, o OS inicializa o objeto de configuração de dispositivo usando o conjunto de objetos de acesso localpara os recursos exigidos. Um objeto de configuração podeinclui configurações adicionais especificadas nos manifes-tos. Um exemplo de configurações adicionais seria uma confi-guração contanto a uma extensão de classificação o formato dados/hora preferenciais do usuário.

Em 414, o OS inicia execução das instruções execu-táveis do acionador de dispositivo. As instruções executá-veis para inicializar o acionador de dispositivo são forne-cidas pelo OS ou sistema de instalação e não pelo programa- dor do acionador de dispositivo.

Em 416, o acionador de dispositivo executando a-cessa os recursos de computação solicitados através de obje-tos de acesso local. Além disso, o acionador de dispositivoexecutando pode somente acessar os recursos de computaçãosolicitados (não outros) e somente via os objetos de acessolocal ligados ou inseridos.

Conclusão

As técnicas, descritas aqui, podem ser implementa-das de muitas formas, incluindo (mas não limitadas a) módu-los de programa, sistemas de computação de propósito geral ede propósito especial, servidores e equipamento de rede, e-letrônica dedicada e hardware, suporte lógico inalterável,como parte de uma ou mais redes de computador, e/ou uma com-binação desses.

Embora uma ou mais implementações descritas acimatenham sido descritas em linguagem especifica para caracte-rísticas estruturais e/ou etapas metodológicas, entende-seque outras implementações podem ser praticadas sem as carac-terísticas ou etapas exemplificadas específicas descritasaqui. De preferência, as características ou etapas exempli-ficadas específicas são descritas como formas preferenciaisde uma ou mais implementações. Em alguns casos, caracterís-ticas bem conhecidas podem ter sido omitidas ou simplifica-das para esclarecimento da descrição das implementações e-xemplifiçadas. Além disso, para facilidade de entendimento,certas etapas de método são traçadas como etapas separadas;entretanto, essas etapas separadamente traçadas não deveriamser construídas como necessariamente ordem dependente de seudesempenho.

Claims

1. Meio legível por processador, CARACTERIZADO porter instruções executáveis por processador que, quandoexecutadas por um processador, executam um método,compreendendo:obter um acionador de dispositivo (300), onde esteé um conjunto de instruções executáveis;determinar um conjunto de recursos de computação(312 e 350) exigidos para execução do conjunto de instruçõesexecutáveis do acionador de dispositivo (300);fornecer um ou mais objetos de acesso local (332,333, 336, 338 e 340) para uso pelo acionador de dispositivo(300) para acesso ao conjunto exigido de recursos decomputação (312 e 350), cada um dos um ou mais objetos deacesso local (332, 333, 336, 338 e 340) compreendendoinstruções executáveis;iniciar execução do conjunto de instruçõesexecutáveis do acionador de dispositivo (300) e as instruçõesexecutáveis de um ou mais objetos de acesso local (332, 333,336, 338 e 340).

2. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a ação de determinarcompreende obter um manifesto legível por computador (142)associado com o acionador de dispositivo (300), o manifestode acionador de dispositivo (142) especificando o conjunto derecursos de computação (312 e 350) exigido para execução doconjunto de instruções executáveis do acionador dedispositivo (300).

3. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o método adicionalmentecompreende confirmar que o acionador de dispositivo (300)está autorizado a acessar o conjunto exigido de recursos decomputação (312 e 350).

4. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a ação de forneceradicionalmente compreende gerar um ou mais objetos de acessolocal (332, 333, 336, 338, e 340) para uso pelo acionador dedispositivo (300) para acesso ao conjunto exigido de recursosde computação (312 e 350), o objeto de acesso local sendofornecido por um sistema operacional.

5. Meio legível por processador, CARACTERIZADO porter instruções executáveis por processador que, quandoexecutadas por um processador, executam um método,compreendendo:obter um módulo de programa não confiável (300)compreendendo um conjunto de instruções executáveis e omódulo de programa não confiável (300) sendo configurado paraacessar um ou mais recursos de computação (312 e 350);determinar um ou mais recursos de computação alvo(312 e 350) do módulo de programa não confiável (300) , ondeum ou mais recursos de computação alvo (312 e 350) sãorecursos de computação (312 e 350) que o módulo de programanão confiável (300) procurará acessar quando o conjunto deinstruções executáveis do módulo de programa não confiável(300) é executado;fornecer um ou mais objetos de acesso localconfiáveis (332, 333, 336, 338 e 340) ao módulo de programanão confiável (300) tal que o módulo de programa nãoconfiável ganhe acesso a um ou mais recursos de computaçãoalvo (312 e 350) via os um ou mais objetos de acesso localconfiáveis (332, 333, 336, 338 e 340).

6. Meio, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que cada um dos objetos de acessolocal confiáveis (332, 333, 336, 338 e 340) está associado aum ou mais recursos de computação (312 e 350) e cada um dosobjetos de acesso local confiáveis (332, 333, 336, 338 e 340)compreende um conjunto de instruções executáveis.

7. Meio, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que cada um dos objetos de acessolocal confiáveis (332, 333, 336, 338 e 340) está associado aum ou mais recursos de computação, cada um dos objetos deacesso local confiáveis (332, 333, 336, 338 e 340) compreendeinstruções executáveis, e o fornecimento adicionalmentecompreende configurar as instruções executáveis de um ou maisobjetos de acesso local confiáveis (332, 333, 336, 338 e 340)para fornecer ao módulo de programa não confiável (300)acesso a um ou mais recursos de computação alvo (312 e 350)via as instruções executáveis configuradas de um ou maisobjetos de acesso local confiáveis (332, 333, 336, 338 e-340).

8. Meio, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que o módulo de programa nãoconfiável (300) é um acionador de dispositivo (300).

9. Meio legível por processador, CARACTERIZADO porter instruções executáveis por processador que, quandoexecutadas por um processador, executam um método,compreendendo:obter um módulo de programa não confiável (300)compreendendo um conjunto de instruções executáveis e omódulo de programa não confiável (300) sendo configurado paraacessar um ou mais recursos de computação (312 e 350);determinar um ou mais recursos de computação alvo(312 e 350) do módulo de programa não confiável (300), ondeum ou mais recursos de computação alvo (312 e 350) sãorecursos de computação (312 e 350) que o módulo de programanão confiável (300) procurará acessar quando o conjunto deinstruções executáveis do módulo de programa não confiável(300) é executado;fornecer um ou mais objetos de acesso localconfiáveis (332, 333, 336, 338 e 340) ao módulo de programanão confiável (300) tal que o módulo de programa nãoconfiável ganhe acesso a um ou mais recursos de computaçãoalvo (312 e 350) via os um ou mais objetos de acesso localconfiáveis providos (332, 333, 336, 338 e 340), os um ou maisobjetos de acesso local confiáveis (332, 333, 336, 338 e 340)estando associados com um ou mais recursos de computação alvo(312 e 350);permitir que o módulo de programa acesse um ou maisrecursos de computação alvo (312 e 350) somente via um oumais objetos de acesso local confiáveis (332, 333, 336, 338 e340) associados com aqueles um ou mais recursos de computaçãoalvo (312 e 350) .

10. Meio, de acordo com a reivindicação 9,CARACTERIZADO pelo fato de que o módulo de programa nãoconfiável (300) é um acionador de dispositivo (300).