[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU
On 12/4/19, Jan Beulich <jbeulich@xxxxxxxx> 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@xxxxxxxxx> > Reported-by: Jeremi Piotrowski <jeremi.piotrowski@xxxxxxxxx> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > > --- 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 */ > > This patch worked building xen-4.12.1 in Buster with python3. I can now boot Focal kernel-5.3 which is LZ4 compressed. The domU can boot as pv, pvh, using direct kernel (kernel/ramdisk), or pygrub. I looked into booting as pvgrub2, thinking the code is universal, but no. Thats why I CC'd Juergen. I wanted to do a kernel direct boot with scripted pvgrub2 kernel. I expect that once I build stubdom including this patch, then pvgrub will work too. Thanks for the attention to this bug, now solved. PryMar56 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |