From: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Pry Mar <pryorm09@gmail.com>
Subject: Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU
Date: Fri, 6 Dec 2019 07:25:35 +0100 [thread overview]
Message-ID: <20191206062535.GA13261@gentoo-tp.home> (raw)
In-Reply-To: <65509778-2d73-6ed4-1537-95c5ae54e36e@suse.com>
On Wed, Dec 04, 2019 at 02:27:26PM +0100, Jan Beulich wrote:
> On 04.12.2019 08:14, Jeremi Piotrowski wrote:
> > Any suggestions how to proceed?
>
> Actually here's a better version (I think).
>
> Jan
>
> lz4: refine commit 9143a6c55ef7 for the 64-bit case
>
> I clearly went too far there: While the LZ4_WILDCOPY() instances indeed
> need prior guarding, LZ4_SECURECOPY() needs this only in the 32-bit case
> (where it simply aliases LZ4_WILDCOPY()). "cpy" can validly point
> (slightly) below "op" in these cases, due to
>
> cpy = op + length - (STEPSIZE - 4);
>
> where length can be as low as 0 and STEPSIZE is 8. However, instead of
> removing the check via "#if !LZ4_ARCH64", refine it such that it would
> also properly work in the 64-bit case, aborting decompression instead
> of continuing on bogus input.
>
> Reported-by: Mark Pryor <pryorm09@gmail.com>
> Reported-by: Jeremi Piotrowski <jeremi.piotrowski@gmail.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- unstable.orig/xen/common/lz4/decompress.c
> +++ unstable/xen/common/lz4/decompress.c
> @@ -147,7 +147,7 @@ static int INIT lz4_uncompress(const uns
> goto _output_error;
> continue;
> }
> - if (unlikely((unsigned long)cpy < (unsigned long)op))
> + if (unlikely((unsigned long)cpy < (unsigned long)op - (STEPSIZE - 4)))
> goto _output_error;
> LZ4_SECURECOPY(ref, op, cpy);
> op = cpy; /* correction */
> @@ -279,7 +279,7 @@ static int lz4_uncompress_unknownoutputs
> goto _output_error;
> continue;
> }
> - if (unlikely((unsigned long)cpy < (unsigned long)op))
> + if (unlikely((unsigned long)cpy < (unsigned long)op - (STEPSIZE - 4)))
> goto _output_error;
> LZ4_SECURECOPY(ref, op, cpy);
> op = cpy; /* correction */
>
Thanks Jan, this works. I tested it with direct kernel boot. Like Pry
wrote pvgrub2 is another story, seems there is no support for lz4
compressed kernels in it , and ubuntu patches in support to the grub that
they ship.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
prev parent reply other threads:[~2019-12-06 6:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 20:33 [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU Pry Mar
2019-10-24 8:12 ` Jan Beulich
2019-12-01 17:47 ` Jeremi Piotrowski
2019-12-02 14:28 ` Andy Smith
2019-12-03 8:02 ` Jan Beulich
2019-12-04 7:14 ` Jeremi Piotrowski
2019-12-04 13:10 ` Jan Beulich
2019-12-04 13:27 ` Jan Beulich
2019-12-05 1:20 ` Pry Mar
2019-12-06 6:25 ` Jeremi Piotrowski [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=20191206062535.GA13261@gentoo-tp.home \
--to=jeremi.piotrowski@gmail.com \
--cc=jbeulich@suse.com \
--cc=pryorm09@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/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).