Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 5 Nov 2018 20:42:03 -0800
From:   Joel Fernandes <joel@joelfernandes.org>
To:     Kees Cook <keescook@chromium.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Anton Vorontsov <anton@enomsg.org>,
        Colin Cross <ccross@android.com>,
        Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes
Message-ID: <20181106044203.GD139199@google.com>
References: <20181101235200.28584-1-keescook@chromium.org>
 <20181101235200.28584-9-keescook@chromium.org>
 <20181102180111.GA14942@google.com>
 <CAGXu5jLcawCKQL9i6poyJu3v3Ru6VcAXqwa5dxKWQL1Bp+Ai_w@mail.gmail.com>
 <20181105044217.GB56850@google.com>
 <CAGXu5jJzszbMOZAj_K0tfBV-3Rs67_gedHd+RwSXvzY38Fu3dA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGXu5jJzszbMOZAj_K0tfBV-3Rs67_gedHd+RwSXvzY38Fu3dA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 05, 2018 at 09:04:13AM -0800, Kees Cook wrote:
> On Sun, Nov 4, 2018 at 8:42 PM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > Dumping the magic bytes of the non decompressable .enc.z files, I get this
> > which shows a valid zlib compressed header:
> >
> > Something like:
> > 48 89 85 54 4d 6f 1a 31
> >
> > The 0b1000 in the first byte means it is "deflate". The file tool indeed
> > successfully shows "zlib compressed data" and I did the math for the header
> > and it is indeed valid. So I don't think the data is insane. The buffer has
> > enough room because even the very small dumps are not decompressable.
> 
> Interesting. So the kernel wouldn't decompress it even though it's the
> right algo and untruncated? That seems worth fixing.

I just can't reproduce the issue though :) I am wondering if it was something
to do with compression being done by an older version of the algorithm or a
buggy algorithm, and the decompressor is newer. Or something.

Not sure if its worth spending more time on, I'll park it for now unless you
want me to dig deeper into it.

- Joel