a maior parte dos mecanismos de seguranca vieram do vax e de outros minicomputadores que durante as decadas de 70, 80 e 90 controlaram arsenais nucleares, usinas, sistemas de controle de trafego aereo e outras aplicacoes de alta seguranca. na pratica, o 68000 eh apenas um vax em um chip, motivo pelo qual eh uma boa introducao sobre o assunto (para desgosto dos velhacos que frequentam o forum e adoram arm).
aqui tem uma pagina interessante, com uma boa introducao ao 68000:
http://www.coe.uncc.edu/~sjkuyath/MC68000/topindex.html
bom, pertinente ao topico eh a questao de seguranca, e que portanto o fabim TEM que dar uma olhada, temos no item 1 o modelo de programacao onde se ve os registros para o usuario e supervisor. a selecao entre um modo e outro eh feito pelo bit 13 do SR (status register), sendo que os bits 15-8 nao sao acessiveis ao usuario e os bits 7-0 sao acessiveis e formam o CCR (condition code register). tentar acessar os bits altos do SR causa uma exception de violacao de privilegios, o que permite punir o usuario.
mas sera que o usuario nao pode tentar zuar o supervisor pela stack? para isso o 68000 possui duas stacks: a SSP (supervisor stack pointer), que eh protegida como a parte alta do SR, e a USP (user stack pointer), que eh a que o usuario vai usar. ele pode pintar e bordar na stack dele, sem afetar o funcionamento do supervisor. eh facil entender isso durante uma interrupcao: em um processador com stack compartilhada, o usuario pode fazer um programa que consiste apenas em apontar a stack para um endereco invalido e entrar em um loop infinito. assim, quando chegar uma interrupcao, o kernel vai empilhar o contexto atual na stack para atender a interrupcao, como ocorre em qq processador desde o pic mais miudinho. soh que daih o processador vai crashar, pq a stack aponta para uma area invalida! entao como prevenir isso? duas stacks. o supervisor atende a interrupcao em sua stack e nao eh afetado pela molecagem do usuario.
existe ainda um set de instrucoes onde algumas sao privilegiadas, em especial acesso a registros de controle e instrucoes especiais como reset e stop. ou seja, o usuario nao consegue dar um stop e parar o processador.
na sessao 5 temos um overview do hardware e de interesse especial na seguranca sao os pinos de controle de acesso FC0-2. eles permitem codificar 8 espacos de enderecamento, sendo 5 realmente utilizados. o supervisor pode acessar qq espaco, inclusive forjar um atendimento de interrupcao via software ao inves de hardware, mas o usuario soh tem acesso aos espacos 1 e 2. o PULO DO GATO eh que FC2 reflete o bit 13 do SR, indicando se esta em modo usuario ou supervisor e FC1 reflete se eh espaco de codigo ou dados.
na decodificacao de enderecos vc leva isso em conta e o kernel coloca para o usuario os codigos dele em um espaco e os dados em outro espaco atraves da linha FC1. se tentarem burlar esse esquema, por exemplo, injetando um shell code maligno via buffer overflow, o 68000 gera uma exception e aborta a aplicacao! perceba que a intel demorou 30 anos para implementar o mesmo na plataforma x86, na forma do bit NX nas tabelas de paginacao da MMU!
a proposito... o proprio x86 soh comecou malemal a ser unix-ready a partir do 286, mas ainda com alguns furos fatais de seguranca. no 386, por exemplo, vc pode desmontar o modo privilegiado (kernel) a partir do modo real (aplicacao) executando uma das famigeradas "instrucoes secretas" do processador. o fato do unico unix para x86 na decada de 80 ter sido o xenix da microsoft tambem nao colabora, motivo pelo qual praticamente toda workstation e server unix da decada de 80 usava 680x0. apesar do 486 ser bem unix-ready, a maioria dos fabricantes unix da decada de 90 preferiu nao arriscar e migrou para maquinas risc. somente com o pentium-pro a intel ganhou confianca suficiente no aspecto de seguranca, mas mesmo assim ignorando coisas basicas (bit NX) e fazendo a festa dos hackers com seus shell codes via buffer overflow!
voltanto entao aos processadores de verdade... tentativas de ganhar acesso supervisor ou burlar interrupcoes ficam entao bloqueadas, pois sem acesso ao SR a aplicacao nao consegue mudar a linha FC2 e portanto os decoders de endereco para as outras areas nao atuam! o mecanismo da linha FC1 tb pode ser usado para reforcar a seguranca no kernel, de modo que um buffer overflow enviado do espaco do usuario para o kernel nao seja executado. ele vai gerar uma exception para ele mesmo e abortar a operacao que estava fazendo, evitando cair em uma falha de seguranca.
bom, soh detalhando como funciona: o 68000 tem bus assincrono, o que significa que qualquer transferencia ocorre com o seguinte handshanking:
a) o 68000 inicia o ciclo gerando enderecamento, codigo de seguranca (FC0-2) e aguarda.
b) o periferico decodifica o endereco e verifica o codigo de seguranca. se nao bater, ele ativa a linha BERR (bus error) e o 68000 aborta para uma exception.
c) se o codigo de seguranca for valido, wait-states sao calculados pelo periferico e ele ativa DTACK (data ack) e o 68000 termina o ciclo corretamente.
eh possivel tambem usar o esquema de try/abort/retry, onde o usuario quer ter acesso a um recurso, mas ele nao esta disponivel e o supervisor (kernel) tem que prover. nesse caso o sistema trabalha com dois 68000 em fase diferente de clock, um adiantado e outro atrasado:
a) os dois 68000 iniciam o ciclo normalmente.
b) o processador adiantado nao passa pelo codigo de seguranca e aborta com BERR, enquanto o 68000 atrasado fica inserindo wait-states. o 68000 adiantado faz o tratamento da exception e gera uma correcao do codigo para que o 68000 atrasado pegue o codigo correto e retorna.
c) o 68000 atrasado recebe uma solicitacao de retry (ativacao simultanea de BERR e HALT), continuando a execucao sem exception e sem abortar a execucao do codigo.
isso era uma ideia na decada de 70, mas tem alguns furos e foi substituido pelo conceito de MMU. com a MMU vc tem uma tabela onde bate os enderecos e codigos de seguranca. mas para usar uma MMU vc precisa de um 68010 ou superior, onde esta inclusa a capacidade de abortar um acesso no meio e continuar do ponto onde parou. nestes processadores a coisa complica, pq eh necessario fazer um dump dos pipelines na stack!
mas isso permite o usuario acessar, por exemplo, um frame buffer e abortar uma instrucao move no meio com BERR. o supervisor entao analisa o estrago, mapeia a area de memoria que o usuario quer acessar e entao retorna. o move que foi abortado no meio continua agora com DTACK e sem a necessidade de um mecanismo tipo try/abort/retry.
bom, eh isso que eu lembro. acho que o mastk e enigma tem que dar uma boa olhada ainda nas sessoes 6, 7 e 8 deste material, pois lah tem umas dicas interessantes sobre bus contention, ou seja, como decodificar enderecos de memoria corretamente sem zuar os barramentos, load analisys, que todo mundo me pergunta sobree nunca acho material para mostrar, e time analisys, que muito importante conhecer para evitar meta-estabilidade nos barramentos quando o 68k fala com FPGAs!
no mais, volto a recomendar para o fabim: leia os livros do taneba!
enigmabox escreveu:Acho que só montando na unha um hardware 68K que vai entender bem o processo modo usuario e modo supervisor.
Tinha feito um tempo atras uma placa com MC68030, onde aprendi varias coisas interessantes com esta CPU. No modo supervisor, falando em assembler, a aplicação(monitor ou kernel) tem acesso a todas instruções e interrupções do 68K, já no modo usuario, o aplicativo(programa do usuario) já trabalha limitado, pois nao pode ter acesso a certas areas da memoria e nem pode executar alguns mnemonicos do 68K, tudo isso devido a segurança e para que uma aplicação nao entre no mesmo espaço de ram de outra aplicação. Para a aplicação no modo usuario executar "algo que uma aplicação no modo supervisor pode executar", só atraves da instrução TRAP.
TRAP pode ser pensado como uma interrupção forçada via software. O aplicativo no modo usuario diz pra CPU executar uma tarefa no modo supervisor.
