Upload
rafaelvitalino
View
11
Download
3
Embed Size (px)
Citation preview
1
UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
IGOR NOGUEIRA SANTOS PERSIS CASTRO ALVES
THIAGO MARÇAL DA SILVA VITOR FERNANDES RIBEIRO DE OLIVEIRA
DESENVOLVIMENTO DE UM SISTEMA DE ARQUIVOS COM SUPORTE À ELIMINAÇÃO DE EVIDÊNCIAS
Salvador
2008
2
IGOR NOGUEIRA SANTOS PERSIS CASTRO ALVES
THIAGO MARÇAL DA SILVA VITOR FERNANDES RIBEIRO DE OLIVEIRA
DESENVOLVIMENTO DE UM SISTEMA DE ARQUIVOS COM SUPORTE À ELIMINAÇÃO DE EVIDÊNCIAS
Trabalho apresentado ao Curso de graduação em Ciência da Computação, Departamento de Ciência da Computação, Instituto de Matemática, Universidade Federal da Bahia, para fins avaliativos na matéria Sistemas Operacionais lecionado pelo professor Luciano Porto Barreto.
Salvador
2008
3
SUMÁRIO
1 INTRODUÇÃO................................................................................................................. 4
2 PROCEDIMENTO ........................................................................................................... 6
3 AVALIANDO DESEMPENHO ....................................................................................... 7
4 REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................... 10
4
1 INTRODUÇÃO
Um sistema de arquivos é um conjunto de estruturas lógicas e de rotinas que
permitem ao sistema operacional controlar o acesso ao dispositivo de armazenamento. Além
de organizar os arquivos no disco, ele também é responsável pela segurança e acesso aos
arquivos que estão armazenados. Tal estrutura é uma das partes mais perceptíveis de um
sistema operacional, pois a manipulação de arquivos é uma das atividades mais comumente
realizadas pelos usuários, devendo sempre acontecer de maneira uniforme e independente dos
diferentes dispositivos de armazenamento [1].
Para tanto, o Linux dá suporte a diversos sistemas de arquivos permitindo uma maior
flexibilidade e coexistência entre muitos outros sistemas operacionais. Devido ao VFS
(Virtual File System) no Linux, pode-se coexistir muitos sistemas de arquivos diferentes
dentro do kernel dando uma interface padrão de acesso a todas elas como: ext, ext2, ext3, ext4,
minix, xia, reiserfs e outras. O VFS interpreta em alto nível as chamadas de sistema de acesso
a arquivos e invoca a função do sistema de arquivo responsável pelo tratamento da chamada.
O VFS é composto por quatro estruturas [2]:
• Superblock: Contêm informações sobre o sistema de arquivo em geral
(dispositivo de montagem, tamanho dos blocos de dados, tamanho máximo
de um arquivo, tipo do sistema de arquivo, ponteiro para as rotinas de
superblock). Toda vez que um sistema de arquivo é montado, um superblock
é criado.
• Inode: Contêm informações sobre um único arquivo (proprietário, grupo,
permissões, data e hora de criação, data e hora de acesso, ponteiros para os
blocos em disco onde ficam alocados os dados do arquivo).
• File: Contêm informações sobre a interação de um arquivo aberto e um
processo (caminho para o arquivo, modo de acesso, estrutura
file_operations). Este objeto só existe quando há o processo está interagindo
com algum arquivo.
• Dentry: Contêm informações que representam o caminho singular a um
arquivo ou diretório (nome do arquivo ou diretório, listas de dentrys pais e
filhos, inode associado ao arquivo ou diretório, estrutura dentry_operations).
Por exemplo, se montarmos um sistema de arquivos como ext3, é executada a
função ext3_read_super(), que efetua a alocação de memória necessária para as estruturas de
5
dados usadas pelo sistema de arquivos e cria-se um superblock. Depois disto, é alocado um
inode para a raiz do sistema de arquivos que permitirá o acesso aos arquivos e diretórios [3].
Para melhorar o desempenho de operações de E/S, os dados são temporariamente
alocados na memória RAM antes de serem gravados em disco. Se houver um problema de
falha elétrica antes dos dados serem efetivamente armazenados, isso pode causar
inconsistência no sistema de arquivos como, por exemplo, de um arquivo que foi removido,
mas seu inode e blocos de dados permaneceram no disco.
Com o surgimento do journaling (periódico) ou logging (anotação), tornou-se o
sistema de arquivos mais resistente a falhas dando mais integridade ao armazenamento já que
as atualizações dos metadados dos arquivos são gravados em um log serial antes que o log
original do disco seja atualizado. Quando uma falha de sistema ocorrer, o sistema de
recuperação de código irá analisar no log de metadados e tentará limpar apenas os dados
inconsistentes através da releitura do arquivo de log.
Como mencionado anteriormente, devido à estrutura do VFS, o Linux suporta
inúmeros sistemas de arquivos. Para esse trabalho, nos atentemos ao sistema de arquivos
EXT3 (Third Extended File System). O sistema de arquivos ext3 é uma versão journaling do
sistema de arquivos ext2. O journal do ext3 é armazenado em um inode, que é um arquivo.
Armazenando o journal em um inode, o ext3 pode adicionar o journal necessário ao sistema
de arquivos sem exigir extensões incompatíveis com o metadado do ext2. Esse é um dos
principais pontos pelo qual o ext3 pode oferecer compatibilidade com ext2 [4].
Basicamente, em um sistema de arquivos ext3, cada arquivo tem dados armazenados
em blocos, inodes e diretórios de entrada. O conteúdo dos arquivos é armazenado em um ou
mais blocos que são de uso exclusivo do arquivo. Dados temporais como a última
modificação, o último acesso, a última mudança, entre outras informações, incluindo o
tamanho do arquivo, compõem os metadados. Os metadados são armazenados em uma
estrutura inode que se localiza numa tabela no início de um determinado grupo de blocos. E o
diretório de entrada que se localiza em um bloco alocado no diretório do arquivo pai,
armazena o nome do arquivo.
Devido a facilidade de recuperação rápida e confiável em caso de falhas no ext3 por
causa do journaling, pode-se notar um aspecto de segurança quanto à recuperação de resíduos
de alguns dados ao serem apagados. Simplesmente, através do journaling, a computação
forense pode usufruí-la para recuperação de dados de algum criminoso virtual que tentou
apagar suas evidências no dispositivo de armazenamento, por exemplo. Ou usuários
6
maliciosos podem obter acesso a dados sigilosos de uma empresa cujos dados foram
eliminados, mas que ainda são válidos.
Há diversos algoritmos e métodos para eliminação total de resíduos de dados que
foram excluídos sem possibilidade de recuperação. Contudo, o que se deseja, nesse contexto,
é modificar o sistema de arquivos ext3 de forma que sua estrutura impeça a recuperação de
informações que foram excluídas pelo usuário.
2 PROCEDIMENTO
O procedimento utilizado foi inicialmente o de verificar o funcionamento do sistema
de arquivos ext3. Então, pode-se ver na figura abaixo que a organização do ext3 adota o
seguinte esquema:
Nesse esquema, cada arquivo é representado por uma estrutura de dados chamada
inode. Um inode, como dito anteriormente, contém informações como tamanho do arquivo,
listas ACL, entre outros. O dado que é mais interessante ao trabalho é a propriedade
i_block[int n], que consiste em um vetor de blocos, que são os blocos de disco onde o arquivo
se encontra armazenado fisicamente. Inicialmente achamos que instruções como inode-
>i_block[i] = 0 poderiam resolver o problema. No entanto, a presença do journal e o controle
das operações por ele imposto nos mostrou que esse não era o caminho a ser seguido. A forma
mais correta de implementar a função em questão seria respeitando a estrutura do sistema de
arquivos. Outra questão era onde colocar a modificação. Depois de dias estudando o código (e
muito printk), reduzimos o universo de scripts para os scripts do ext3 e dentre eles, os mais
prováveis seriam inode.c, namei.c ou balloc.c. Optamos pelo balloc por ter funções mais
7
específicas ao universo de blocos de disco. A modificação foi implementada dentro da função
ext3_free_blocks, que “libera” os blocos do arquivo apagado para reuso.
Originalmente, ao remover um arquivo, o ext3 basicamente apaga os links para os
blocos e zera o tamanho do inode. A recuperação, dessa forma, é bastante simples, porque os
dados reais não são apagados até que o bloco seja realocado a outro inode e sobrescrito por
ele. Dessa forma, para prover uma remoção segura, implementamos uma modificação que
sobrescreve os blocos com 0’s antes dos mesmos serem liberados. Abaixo segue o trecho
implementado na função ext3_free_bocks do arquivo balloc.c:
Procuramos evitar também a recuperação dos metadados do arquivo. Para isso,
dentro da função ext3_delete_inode do arquivo inode.c, implementamos o seguinte trecho:
Com isso os metadados do arquivo seriam zerados inviabilizando a recuperação do
mesmo.
3 AVALIANDO DESEMPENHO
Para avaliar o impacto dessa modificação no sistema de arquivos, foi realizado um
benchmarking medindo o tempo de execução da instrução rm [5] ao realizar a exclusão de um
arquivo. E para medir o tempo de execução de uma instrução utilizou-se o comando time [6],
que acompanhado de outro comando subseqüente, mostra informações sobre o tempo de
execução dessa instrução subseqüente.
inode->i_uid = novas_info;
inode->i_gid = novas_info;
inode->i_atime.tv_sec = 0;
inode->i_atime.tv_nsec = 0;
inode->i_mtime.tv_sec = 0;
inode->i_mtime.tv_nsec = 0;
inode->i_ctime.tv_sec = 0;
inode->i_ctime.tv_nsec = 0; EXT3_I(inode)->i_dtime = 0;
for (cont = block; cont < block + count; cont++ ) {
bh = sb_getblk(sb, cont);
lock_buffer(bh);
memset(bh->b_data,0,bh->b_size);
unlock_buffer(bh);
mark_buffer_dirty(bh);
set_buffer_jbddirty(bh);
brelse(bh); }
8
Para automação do processo de medição de tempo, utilizou-se um shell script [7]
para gerar os arquivos que seriam utilizados, para realizar a exclusão do arquivo e medir o
tempo de execução da instrução, conforme descrito abaixo:
O comando time retorna três valores na seguinte ordem [8]:
1. Real: é o tempo real passado entre a chamada e o término da instrução;
2. User: é o tempo de utilização da CPU pelo usuário (a soma de tms_utime e
tms_cutime valores em uma struct tms como retornado por times(2))
3. Sys: é o tempo de utilização CPU pelo sistema (a soma do tms_stime e
tms_cstime valores em uma struct tms como retornado por times(2))
Como o importante neste trabalho é o tempo de execução real da instrução nesse
novo sistema de arquivos, atentemos ao valor Real do comando time.
O script foi executado utilizando o sistema de arquivos EXT3 e EXT3Modificado,
cada um em sua instância, para medir o tempo de execução da instrução rm e foram obtidos
os seguintes valores:
Arquivo
Tempo de
Execução no
Sistema de
Arquivos EXT3
(segundos)
Tempo de
Execução no
Sistema de
Arquivos
EXT3Modificado
(segundos)
1 0,050 0,049
2 0,048 0,051
3 0,049 0,049
4 0,048 0,048
5 0,049 0,050
#!/bin/bash
#Cria 20 arquivos textos para teste
for i in $(seq 20); do
echo 'Conteúdo do arquivo texto.' > arquivo$i.txt
done
#Para excluir os arquivos criados anteriormente entro nesse loop
for i in $(seq 20); do
echo "Tempo de exclusão do arquivo$i.txt:"
#Realiza a exclusao do arquivo
#E mede-se o tempo de execucao do comando rm
time rm arquivo$i.txt
done
9
6 0,050 0,052
7 0,051 0,047
8 0,076 0,086
9 0,077 0,076
10 0,073 0,076
11 0,067 0,080
12 0,059 0,064
13 0,071 0,069
14 0,086 0,072
15 0,059 0,067
16 0,070 0,079
17 0,074 0,087
18 0,058 0,085
19 0,082 0,070
20 0,069 0,082
Valor Médio 0,0633 0,0670
Desvio Padrão 0,0126 0,0145
Variância 0,0002 0,0002
Valor Médio
0,0610
0,0620
0,0630
0,0640
0,0650
0,0660
0,0670
0,0680
EXT3 EXT3Modificado
Sistema de Arquivos
Tem
po d
e E
xecução d
a
Instr
ução (s)
Para arquivos maiores temos, há de se notar uma diferença. Sem o patch, um
arquivo de 16MB leva 0,094s para ser removido. Com as modificações, o tempo de remoção
é de 0,155s. Todos os testes foram realizados sobre o sistema operacional Ubuntu 2.6.24 (com
10
512MB de RAM) virtualizado com o Vmware Workstation 6.0 sobre Windowes XP - Service
Pack 2, Pentium D 2.8 e 1,5 GB de RAM.
De acordo com os resultados obtidos nota-se que o sistema de arquivos modificado
leva um tempo maior na sua execução devido ao conjunto das novas instruções adicionadas
no sistema de arquivos para realizar a sobrescrita dos blocos. Contudo a adição delas não
prejudica exageradamente o tempo de execução da instrução já que os desvios-padrão foram
mínimos indicando homogeneidade nos tempos de exclusão. Portanto, o sistema de arquivos
criado apresenta um bom desempenho quanto ao tempo de execução na exclusão total de um
arquivo.
4 REFERÊNCIAS BIBLIOGRÁFICAS
[1] Dodonov, E. (2001) - Abordando Sistema de Arquivos do Linux. In USP 2001.
[2] Wikipédia - Sistemas de Arquivos Virtual -
http://pt.wikipedia.org/wiki/Sistemas_Arquivo_virtual
[3] Ferreira, E. L., Ramos, L. F. (2006) - Sistema de Arquivos no Linux. In CEFET-MT.
[4] Sistemas de arquivos ext3 - Guia de Administração de Sistema - Capítulo 1 -
http://web.mit.edu/rhel-doc/3/rhel-sag-pt_br-3/ch-ext3.html
[5] Linux and Unix rm Command Help - http://www.computerhope.com/unix/urm.htm
[6] Linux Man Page - http://linux.die.net/man/1/time
[7] Wikipédia - http://pt.wikipedia.org/wiki/Shell_script
[8] Máximo, F. (2005) - Método curioso de comparação de desempenho - http://www.dicas-
l.com.br/dicas-l/20050930.php