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
Date: Mon, 5 Nov 2018 20:42:03 -0800 [thread overview]
Message-ID: <20181106044203.GD139199@google.com> (raw)
In-Reply-To: <CAGXu5jJzszbMOZAj_K0tfBV-3Rs67_gedHd+RwSXvzY38Fu3dA@mail.gmail.com>
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
prev parent reply other threads:[~2018-11-06 4:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 23:51 [PATCH 0/8] pstore improvements (pstore-next) Kees Cook
2018-11-01 23:51 ` [PATCH linux-next 1/8] pstore/ram: Standardize module name in ramoops Kees Cook
2018-11-01 23:51 ` [PATCH 2/8] pstore: Do not use crash buffer for decompression Kees Cook
2018-11-02 18:24 ` Joel Fernandes
2018-11-14 7:56 ` Kees Cook
2018-11-20 21:43 ` Joel Fernandes
2018-11-29 22:06 ` Kees Cook
2018-11-30 2:26 ` Joel Fernandes
2018-11-01 23:51 ` [PATCH 3/8] pstore/ram: Report backend assignments with finer granularity Kees Cook
2018-11-01 23:51 ` [PATCH 4/8] pstore/ram: Add kern-doc for struct persistent_ram_zone Kees Cook
2018-11-01 23:51 ` [PATCH 5/8] pstore: Improve and update some comments and status output Kees Cook
2018-11-01 23:51 ` [PATCH 6/8] pstore: Replace open-coded << with BIT() Kees Cook
2018-11-01 23:51 ` [PATCH 7/8] pstore: Remove needless lock during console writes Kees Cook
2018-11-02 18:32 ` Joel Fernandes
2018-11-02 20:40 ` Kees Cook
2018-11-02 21:50 ` Joel Fernandes
2018-11-01 23:52 ` [PATCH 8/8] pstore/ram: Correctly calculate usable PRZ bytes Kees Cook
2018-11-02 18:01 ` Joel Fernandes
2018-11-02 20:00 ` Kees Cook
2018-11-05 4:42 ` Joel Fernandes
2018-11-05 17:04 ` Kees Cook
2018-11-06 4:42 ` Joel Fernandes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181106044203.GD139199@google.com \
--to=joel@joelfernandes.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).