Re: About support XZ-compressed kernel on x86

[Lasse Collin <lasse.collin@tukaani.org>]

On 2016-02-18 Baoquan He wrote:
> OK. I still don't understand below snippet taken from misc.c. As you
> said overwriting happened when the write position quickly approaches
> the read position. how could it happpen if the input pointer is moving
> faster than the output pointer?
> 
> 
>  * The output pointer can only overrun the input pointer if the input
>  * pointer is moving faster than the output pointer.  A condition only
>  * triggered by data whose compressed form is larger than the
>  * uncompressed
>  * form.

That paragraph is confusing, I agree. Here is a slightly clearer
wording:

 * The output pointer can only overrun the input pointer if, at some
 * point in the decompression process, the input pointer is moving
 * faster than the output pointer.  This condition can only be
 * triggered by data whose compressed form is larger than the
 * uncompressed form.

I'm afraid it's still not good enough.

Example: Imagine a decompressor whose decompressor loop, on each
iteration, first reads exactly one input byte and then writes at least
one output byte, until all the data has been decompressed. In this case
the input pointer never moves faster than the output pointer (they can
move at the same speed though).

This kind of decompressor would need no safety margin for in-place
decompression: After reading the last input byte, the decompressor
would write one or more output bytes of which the last one would be at
the same position as the last input byte was. If the output pointer
overtook the input pointer at any point, the last input byte would make
the decompressor write past the end of the buffer. That is, the output
pointer overtaking the input pointer would be a clear sign that the
input file is corrupt: Since the input pointer cannot move faster than
the output pointer, the input pointer cannot catch up with the output
pointer so that the last output byte wouldn't be written past the end
of the buffer.

I hope the above example is clear enough; I'm not able to word it
better right now. I don't recommend putting the above example in
misc.c, but maybe the example helps in figuring out a better wording
for the existing text in misc.c.

In most decompressors, the input pointer moves faster than the output
pointer in certain common situations (like file format headers), thus
some decompressor-specific safety margin is needed.

-- 
Lasse Collin  |  IRC: Larhzu @ IRCnet & Freenode