diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/liblzma-security.txt | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/liblzma-security.txt b/doc/liblzma-security.txt index 487637ed..78947bd8 100644 --- a/doc/liblzma-security.txt +++ b/doc/liblzma-security.txt @@ -87,7 +87,7 @@ Using liblzma securely The simplest solution is to use setrlimit() if the kernel supports RLIMIT_AS, which limits the memory usage of the whole process. For more portable and fine-grained limitting, you can use - memory limitter functions found from <lzma/memlimit.h>. + memory limiter functions found from <lzma/memlimit.h>. 1.2.1. Encoder @@ -118,24 +118,24 @@ Using liblzma securely 1.2.2. Decoder - A single-threaded decoder should simply use a memory limitter and + A single-threaded decoder should simply use a memory limiter and indicate an error if it runs out of memory. Memory-limitting with multi-threaded decoding is tricky. The simple solution is to divide the maximum allowed memory usage with the maximum allowed threads, and give each Block decoder their own - independent lzma_memory_limitter. The drawback is that if one Block + independent lzma_memory_limiter. The drawback is that if one Block needs notably more RAM than any other Block, the decoder will run out of memory when in reality there would be plenty of free RAM. - An attractive alternative would be using shared lzma_memory_limitter. + An attractive alternative would be using shared lzma_memory_limiter. Depending on the application and the expected type of input, this may either be the best solution or a source of hard-to-repeat problems. Consider the following requirements: - You use at maximum of n threads. - x(i) is the decoder memory requirements of the Block number i in an expected input Stream. - - The memory limitter is set to higher value than the sum of n + - The memory limiter is set to higher value than the sum of n highest values x(i). (If you are better at explaining the above conditions, please @@ -150,7 +150,7 @@ Using liblzma securely Most .lzma files have all the Blocks encoded with identical settings, or at least the memory usage won't vary dramatically. That's why most multi-threaded decoders probably want to use the simple "separate - lzma_memory_limitter for each thread" solution, possibly fallbacking + lzma_memory_limiter for each thread" solution, possibly fallbacking to single-threaded mode in case the per-thread memory limits aren't enough in multi-threaded mode. @@ -206,7 +206,7 @@ FIXME: Memory usage of Stream info. creating a denial of service like piping decoded a Data Block to another process would do. - At first it would seem that using a memory limitter would prevent + At first it would seem that using a memory limiter would prevent this issue as a side effect. But it does so only if the application requests liblzma to allocate the Extra Records and provide them to the application. If Extra Records aren't requested, they aren't |