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