Re: [Xen-devel] [PATCH] libxc: don't fail domain creation when unpacking initrd fails

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/10/17 17:19, Jan Beulich wrote:
>>>> On 16.10.17 at 17:45, <ian.jackson@xxxxxxxxxxxxx> wrote:
>> Jan Beulich writes ("[PATCH] libxc: don't fail domain creation when 
>> unpacking 
>> initrd fails"):
>>> At least Linux kernels have been able to work with gzip-ed initrd for
>>> quite some time; initrd compressed with other methods aren't even being
>>> attempted to unpack. Furthermore the unzip-ing routine used here isn't
>>> capable of dealing with various forms of concatenated files, each of
>>> which was gzip-ed separately (it is this particular case which has been
>>> the source of observed VM creation failures).
>> I'm not sure I really like this approach of attempting to ungzip it
>> and then falling back.  (And the size-checking logic is not
>> particularly easy to follow.)
>>
>> Is there no way to tell that a kernel supports gzipped initrds by
>> looking at the kernel ?
> Well, Linux kernels have config options controlling their ability. So
> even a modern kernel _could_ be configured to require unzipping.
> I didn't check whether they announce this anywhere outside the
> (possibly) embedded .config, but even if they did this would be
> only Linux then. A solution here shouldn't really be OS-specific imo.
>
>>  A heuristic would probably do: it's OK if we
>> sometimes insist on decompression ourselves, for a subset of old
>> kernels where it's not needed.
> Well, I specifically wanted to avoid any guesswork. But if I
> simply had reported this as a problem that needs dealing with,
> things likely would have gone like for the Python version issue
> (which I still haven't got around to), asking me to look into
> addressing it. So I thought I'd present a possible solution right
> away. To be honest, if you want this to be done some
> meaningfully different way which I'm not convinced of, I'm not
> sure I'm the one to carry this out, yet I'd still request the
> issue to be addressed.

I've been bitten by this issue several times before, and a fix would be
nice.

IMO, the toolstack should not be making assumptions about the initrd,
and shouldn't be touching it.  It is the users responsibility to provide
an initrd which its kernel can read.

Furthermore, leaving the decompression to the kernel reduces the dom0
attack surface.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel