[Pkg-xen-devel] Bug#994870: Memory allocation problem for VM after xen security update

[Hans van Kranenburg]

Hi!,

Please don't (accidentally) drop the debian bug email from the recipient
list. This information might also be useful for others later.

On 9/23/21 1:47 AM, H.-R. Oberhage wrote:
> Good evening Hans,
> 
> On 22.09.2021 20:54, Hans van Kranenburg wrote:
>> Hi Ruediger,
>>
>> On 9/22/21 11:37 AM, H.-R. Oberhage wrote:
>>> Package: xen-system-amd64
>>> Version: 4.14.3-1~deb11u1
>>>
>>> After applying the buster security update to xen, my VM won't start
>>> any longer, complaining about a memory allocation error.
>>
>> Can you confirm that this is a virtual machine that tries to boot a
>> 32-bit kernel as PV type?
> 
> yes, your assumption ...
> 
>> The error message you are seeing is not particularly helpful, but it is
>> most likely related to this.
> 
> ... is correct.
> 
>> The fact that with this package update 32-bit PV guests fail to start 
>> is
>> indeed a regression problem, which is quite inconvenient for you, right 
>> now.
> 
> Ok, then I will put the Xen-package on "hold" for now.
> 
>> At this point I would really recommend to not wait for a fix to arrive
>> which makes it start again, but change your VM to use a 64-bit kernel.
> 
> It really is a shame, that 32-bit isn't supported properly any longer.
> The address- and data-overhead in 64-bit machines only using a 32-bit
> address- and data-space is considerable.
> 
> I already experienced, "bullseye" not supporting a dom0-Kernel for the
> i686-pae architecture any longer :-(. A shame that it doesn't come with
> a kernel before 5.9, which would still allow this.
> 
>> Let me know if you need help or run into problems while making this 
>> change.
> 
> Would you know of a "simple" way to convert/clone a 32-bit VM to a
> work-alike 64-bit one? One has to replace all the .debs for this, after
> all.

The smallest amount of work to initially get your VM going again is to
only install the 64 bit kernel and keep running a 32 bit user land.

The process to fully change from a 32 to 64 system (in place) is called
'cross grading'. I found instructions at
https://wiki.debian.org/CrossGrading

I never did this myself, though.

>> Running 32-bit PV at all is already 'on life support' upstream for 
>> quite
>> a while now, and it also not under security support any more.
> 
> Well it's a Debian "stretch" one, so it's just working for now :-).

One of the main reasons why it's so problematic to keep around is that
in the 32 bit PV case, there are no possibilities to implement fixes for
all the speculative vulnerabilities that have been very much in the news
in the last years.

More about this: https://xenbits.xen.org/xsa/advisory-370.html

>> In the long run, I'd suggest working towards having 64-bit guests in 
>> PVH
>> mode, since that's one of the best options we have these days.
> 
> Thanks, I'll consider this for any newer VMs.
> Are 64-bit PV VMs automatically "moved" to or executed as PVH?
> I would even be willing to edit the .xml/.cfg-file manually.
> I see "bullseye's" virt-manager/libvirt offering only choices for
> "xen (fullvirt)", "xen (paravirt)", or xen", when creating a new
> VM.

It should be as simple as changing type="pv" to type="pvh" in the config
file. In Debian, using PVH this is possible since Buster. Also, using
the xen variant of grub2 (grub-xen and grub-xen-host) is possible.

More info:
https://wiki.xenproject.org/wiki/Understanding_the_Virtualization_Spectrum

Have fun,
Hans