2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-29 18:13:32 -04:00
|
|
|
|
2012-12-10 14:05:59 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
2013-08-28 14:40:12 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-12-10 14:05:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
2010-07-27 11:54:40 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
2012-02-20 17:53:05 -05:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
|
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-20 17:53:05 -05:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
|
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-19 22:07:02 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-11-05 00:14:04 -05:00
|
|
|
|
2014-05-27 12:48:55 -04:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2008-10-09 11:15:52 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2010-06-14 09:54:48 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2013-04-19 17:53:09 -04:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2010-05-16 20:00:00 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2010-05-16 20:00:00 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2010-05-16 20:00:00 -04:00
|
|
|
|
2007-07-19 01:48:04 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2007-07-19 01:48:08 -07:00
|
|
|
|
2007-07-19 01:48:04 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2007-07-19 01:48:08 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2014-08-29 20:52:15 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-09 11:15:52 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2011-01-10 12:10:55 -05:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2008-10-09 11:15:52 -04:00
|
|
|
|
|
|
|
|
|
[PATCH] handle ext4 directory corruption better
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.
At best, the filesystem catches the corruption gracefully. At worst,
things spin out of control.
As you might guess, we found a couple places in ext4 where things spin out
of control :)
First, we had a corrupted directory that was never checked for
consistency... it was corrupt, and pointed to another bad "entry" of
length 0. The for() loop looped forever, since the length of
ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over... I modeled this check and subsequent action on
what is done for other directory types in ext4_readdir...
(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases. Thanks for the idea, Andreas).
Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem. There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.
Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext4.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:36:28 -08:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
[PATCH] handle ext4 directory corruption better
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.
At best, the filesystem catches the corruption gracefully. At worst,
things spin out of control.
As you might guess, we found a couple places in ext4 where things spin out
of control :)
First, we had a corrupted directory that was never checked for
consistency... it was corrupt, and pointed to another bad "entry" of
length 0. The for() loop looped forever, since the length of
ext4_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over... I modeled this check and subsequent action on
what is done for other directory types in ext4_readdir...
(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases. Thanks for the idea, Andreas).
Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem. There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.
Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext4.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Cc: <linux-ext4@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:36:28 -08:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2013-01-28 21:23:24 -05:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
2012-04-29 18:41:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-12-10 14:05:58 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-18 13:15:47 -04:00
|
|
|
|
|
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
ext4 crypto: reorganize how we store keys in the inode
This is a pretty massive patch which does a number of different things:
1) The per-inode encryption information is now stored in an allocated
data structure, ext4_crypt_info, instead of directly in the node.
This reduces the size usage of an in-memory inode when it is not
using encryption.
2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode
encryption structure instead. This remove an unnecessary memory
allocation and free for the fname_crypto_ctx as well as allowing us
to reuse the ctfm in a directory for multiple lookups and file
creations.
3) We also cache the inode's policy information in the ext4_crypt_info
structure so we don't have to continually read it out of the
extended attributes.
4) We now keep the keyring key in the inode's encryption structure
instead of releasing it after we are done using it to derive the
per-inode key. This allows us to test to see if the key has been
revoked; if it has, we prevent the use of the derived key and free
it.
5) When an inode is released (or when the derived key is freed), we
will use memset_explicit() to zero out the derived key, so it's not
left hanging around in memory. This implies that when a user logs
out, it is important to first revoke the key, and then unlink it,
and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to
release any decrypted pages and dcache entries from the system
caches.
6) All this, and we also shrink the number of lines of code by around
100. :-)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-18 13:17:47 -04:00
|
|
|
|
2015-05-01 16:56:45 -04:00
|
|
|
|
2015-05-18 13:15:47 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2009-02-14 23:01:36 -05:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 01:09:05 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-03-02 17:24:05 -05:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
2012-12-17 15:59:39 -08:00
|
|
|
|
2012-04-30 13:14:03 -05:00
|
|
|
|
|
|
|
|
|
2012-12-17 15:59:39 -08:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-01-23 15:56:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2014-01-23 15:56:10 -08:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-11 19:27:31 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-07-27 11:56:04 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2015-04-12 00:56:26 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2012-03-19 23:41:49 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
|
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
2008-08-19 21:57:43 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2008-10-25 11:39:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-31 13:34:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-08 22:25:24 -04:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
2006-10-11 01:21:24 -07:00
|
|
|
|
2006-10-11 01:20:53 -07:00
|
|
|
|
2006-10-11 01:20:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
2014-07-28 13:06:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-17 16:08:53 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-31 13:34:57 -04:00
|
|
|
|
2012-03-18 22:44:40 -04:00
|
|
|
|
|
|
|
|
|