Sumário. Sistemas Operativos 1

Transcrição

1 Sumário Requisitos mínimos do hardware para suportar um SO protegido (ex: Windows/Linux) Mecanismos hardware de suporte nas arquitecturas x86/x64 Sequência de chamada de serviços sistema no Windows a 32 bits Objectivos de aprendizagem Sistemas Operativos 1

2 Requisitos mínimos do hardware para suporte de SOs protegidos Mínimo de 2 níveis de privilégio execução Modo Utilizador (User Mode), Modo Supervisor (Kernel Mode) Instruções privilegiadas (geram excepção se executadas no modo user) Comutação controlada entre modos de execução MMU Memory Management Unit Suporte à criação de espaços de endereçamento virtuais MMU peça hardware entre CPU e RAM, que converte endereços virtuais (CPU) em endereços físicos (RAM) Periféricos inteligentes Suportar a execução de operações de I/O de forma independente do CPU. Interrupções e DMA Timer Suporta a base de tempo do sistema e a garantia que nehum processo se executa mais tempo que o determinado pelo SO. Sistemas Operativos 2

3 Visão geral do mecanismo de suporte a system calls Em todas as arquitecturas que suportam interrupções tem de existir uma tabela consultada pelo hardware onde se especifica o endereço da função handler para cada interrupção e o nível de privilégio em que o código executa. Em geral os handlers de interrupção correm em modo kernel. Uma vez que em geral a invocação do handler de interrupção é realizado programaticamente (instrução int <n> em x86/x64), é também necessário indicar, de modo a impossibilitar chamadas não controladas do handler, o necessário nível de privilégio do caller. Tipicamente uma entrada desta tabela é reservada para a chamada de serviços de sistema (system calls). Tabela de interrupções Espaço de endereçamento N Nível necessário do caller Nível do Handler Handler Handler de system calls SYSCALL_IDX User Kernel 1 Kernel Kernel Handler de Interrupção 1 0 Sistemas Operativos 3

4 Níveis de privilégio de execução nas arquitecturas x86/x64 Este slide e os seguintes apresentam com algum detalhe os mecanismos que suportam a execução privilegiada de código nas arquitecturas x86 Um executável nas plataformas x86/x64 é constituído por vários segmentos de código (e dados). Cada segmento é descrito e conhecido pelo hardware por um descritor de segmento (segment descriptor) que, entre outros itens, inclui: Tipo do segmento (código, dados, etc.) Endereço base e dimensão do segmento. Nível de privilégio (de 0 a 3, indicando 0 o nível mais privilegiado). No Windows apenas são utilizados os níveis extremos: Nível 3 modo User Nível 0 modo Kernel Níveis de privilégio (0 é o nível de maior privilégio) No caso dos segmentos de dados o nível de privilégio presente no descritor indica que apenas código com o mesmo nível de privilégio ou superior (numericamente inferior) lhe tem acesso. No caso de segmentos de código o nível de privilégio indicado no descritor define o privilégio do código do respectivo segmento. Apenas pode haver chamada directa de código quando o chamador tem o mesmo nível de privilégio do chamado. Resulta numa excepção gerada pelo CPU uma chamada directa de código a executar em modo user (3) para modo kernel (0) Sistemas Operativos 4

5 Tabela de descritores de segmentos (GDT) Os descritores de segmentos, definidos pelo SO para cada processo, são armazenados numa tabela global presente em memória principal denominada GDT Global Descriptor Table, que suporta até 8192 entradas. O código presente em cada um dos segmentos de código executa-se com o privilégio especificado no seu descriptor, no campo DPL Descriptor Privilege Level. Não é possível a código User adulterar a protecção do seu ou de outro código pois as instruções que referem o registo GDTR só podem ser executadas por código com nível de privilégio e a memória onde está presente a GDT é inacessível em modo User (a ver mais tarde, quando se falar de gestão de memória) Global Segment Descripor Table (GDT) Segment Descriptor Tipo Dimensão Endereço Base 0 DPL (Descriptor Privilege Level) GDTR Registo que contém o endereço físico da tabela de descritores de interrupção (apenas acessível em nível 0) Sistemas Operativos 5

6 Resolução pelo hardware do handler associada a uma interrupção As interrupções podem ocorrer de forma assíncrona, geradas por periféricos, ou de forma síncrona com a execução de código, através de excepções (ex: tentativa de utilização de instrução privilegiada, divisões por zero, etc), ou ainda por invocação explícita da instrução int. São suportadas 256 interrupções distintas, sendos os respectivos handlers registados em descritores de interrupção presentes numa tabela global, a IDT. O campo DPL Descriptor Privilege Level., em cada descritor, indica o privilégio necessário ao código para invocar de forma explícita a interrupção (através da instrução int). Interrupção IDTR Interrupt Descriptor Table (IDT) Intr. descriptor Registo que contém o endereço físico da tabela de descritores de interrupção (apenas acessível em nível 0) Interrupt Descriptor offset do handler no code segment Segment selector (GDT index) DPL Code Segment que contém o handler da interrupção handler GDT Desc. Segmento Segment Descriptor Dimensão Endereço Base DPL Sistemas Operativos 6

7 Comutação de stack envolvida em transições de níveis de privilégio Quando é invocada uma interrupção de forma explícita (instrução int <n>) ou não, se o nível de execução corrente for diferente (menor) que o do segmento que contém o handler da interrupção, haverá lugar a uma comutação de stack, efectuada automaticamente pelo hardware, na transição de nível. É necessário que o SO defina, por cada processo, o stack correspondente ao nível de privilégio segmento do handler (tipicamente nível 0) e o dê a conhecer ao hardware, através de um registo de sistema. De uma forma mais sucinta: Se chamar CL ao nível de execução corrente, DPLi ao nível especificado no descritor de interrupção e DPLs o nível do segmento que contém o handler então é obrigatório que: CL = DPLi (para uma invocação explícita) Se DPLi > DPLs então ocorre comutação de stack. A comutação de stack é necessária para garantir que o código menos privilegiado não pode analisar à posteriori as stack frames construídas pelo handler de interrupção, o que poderia comprometer a segurança do sistema. O stack e o código original são repostos no final da execução do handler (através da instrução iret). Stack original Stack pointer Stack handler SP original End. retorno Stack pointer Comutação De stacks Sistemas Operativos 7

8 Invocação controlada de código de kernel O mecanismo de despacho de handlers de interrupção apresentado nos slides anterior é a forma tradicional dos sistemas operativos exportarem os seus serviços na arquitectura x86 (também designada IA-32). Uma vez que existe um número limitado de interrupções disponíveis é usada uma única entrada de interrupção para todos os serviços. No Windows a 32 bits até ao Windows XP era usada a entrada 0x2e da tabela de interrupções, para expor em modo user o handler que processa os system calls. Em versões anteriores do Linux em x86 era usada para o efeito a entrada 0x80. O mecanismo implica uma série de validações de protecção e necessita de obter informação adicional (ex: o stack para o qual se comuta), o que o torna relativamente lento, com um tempo de execução duas ordens de grandeza superior a uma chamada simples de função. As versões mais recentes dos CPU s das arquitecturas Intel introduziram alternativas mais eficientes, mas mesmo assim de custo muito superior ao da chamada uma função: Em x86, o par SYSENTER/SYSEXIT Em x64, o par SYSCALL/SYSRET Convenções de chamada: No Windows a 32 bits, quer usando int quer usando sysenter todos os parâmetros são passados em stack, devido ao número limitado de registos disponíveis No Windows a 64 bits, que usa syscall os 4 primeiros parâmetros são passados por registo, sendo os restantes, caso existam, passados por stack. O slide seguinte apresenta o detalhe da chamada de um serviço do SO utilizando a instrução INT/IRET Sistemas Operativos 8

9 System Calls- sequência de acções na execução Passos na execução de um system call no Windows a 32 bits (via instrução int). Invocar stub presente em ntdll.dll passando parâmetros por stack. Carregar em eax o número do serviço Carregar em edx o endereço no stack do primeiro parâmetro Execução da instrução que comuta para modo kernel (interrupção software - int 0x2e) User Mode Mudança de privilégio e comutação para o stack de kernel Kernel Mode Handler de system call: Se número de system call é valido Salva registos Copia argumentos do stack user para o stack kernel Usa uma tabela de ponteiros para invocar a implementação do serviço Repor registos excepto os que correspondam a retorno do serviço (eax). Retorno para user mode (iret) Sistemas Operativos 9

10 Ferramentas utilizadas nas demonstrações Compilador de c (cl) : cl /Zi <fontes.c> <objectos.obj> a opção /Zi é usada para gerar informação de debug) o cl invoca internamente o linker para gerar o ficheiro executável Assembler 32 bits (ml) e 64 bits(ml64) ml c <file.asm> Executor de makefiles (nmake) Visual studio como debugger devenv <executável.exe> Sistemas Operativos 10

11 Objectivos de aprendizagem Compreensão da necessidade de disponilização pelo hardware de pelo menos dois níveis de privilégio de execução de código Compreensão do mecanismo de despacho de interrupções/excepções e sua utilização na chamada de serviços. Compreensão da necessidade de comutação de stacks na transição para modo kernel Sensibilidade para o custo de uma chamada ao SO Poderá encontrar Informação adicional (embora já desactualizada nalguns detalhes de menor importância) em: Sistemas Operativos 11