W dniu 13.11.2017 o 04:42, Chris Murphy pisze:
> Strange. I was using 4.3.3 and it had been running for over 9 hours at
> the time I finally cancelled it.
If you're compiling from source, the usual advice would be to "make clean" and
make sure you're using the correct executable.
If your fs is very large then caching may be a problem. With the brute force
method it was a good idea to cache the results. With the "reverse crc" method
caching is not very useful. It's only marginally faster on my root fs, and on
larger filesystems searching the cache will be slower than finding collisions.
You can remove the code and see if it makes any difference:
diff --git a/image/main.c b/image/main.c
index 4cffbdba..f77b1504 100644
--- a/image/main.c
+++ b/image/main.c
@@ -500,19 +500,9 @@ static char *find_collision(struct metadump_struct *md,
char *name,
u32 name_len)
{
struct name *val;
- struct rb_node *entry;
- struct name tmp;
int found;
int i;
- tmp.val = name;
- tmp.len = name_len;
- entry = tree_search(&md->name_tree, &tmp.n, name_cmp, 0);
- if (entry) {
- val = rb_entry(entry, struct name, n);
- free(name);
- return val->sub;
- }
val = malloc(sizeof(struct name));
if (!val) {
@@ -548,7 +538,6 @@ static char *find_collision(struct metadump_struct *md,
char *name,
}
}
- tree_insert(&md->name_tree, &val->n, name_cmp);
return val->sub;
}
>
>> Unfortunately there are no CRC32 collisions for any file name having 4 or
>> less characters when you have to keep the same file name length, and there
>> may be no collisions for longer file names when you limit the result to
>> ASCII only.
> Gotcha.
Yeah, it also means for short file names an attacker can easily find the real
name by finding all collisions and filtering out obviously nonsensical names,
so it's more of an obfuscation than sanitization :/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
