Pkg xen devel - Jan 2018 - Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

On 01/12/2018 12:43 PM, Valentin Vidic wrote:
> On Fri, Jan 12, 2018 at 01:34:10AM +0100, Hans van Kranenburg wrote:
>> Is the 59 your lots-o-vcpu-monster?
> 
> Yes, that is the one with a larger vcpu count.
Check.
>> I just finished with the initial preparation of a Xen 4.10 package for
>> unstable and have it running in my test environment.
> 
> Unrelated to this issue, but can you tell me if there is a way to
> mitigate Meltdown with the Xen 4.8 dom0/domU(PV) running stretch?
There are no updates for the hypervisor itself yet that we can
distribute in Debian.

This is your starting point for information:

https://xenbits.xen.org/xsa/advisory-254.html
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/

So, 64-bit PV guests can attack the hypervisor and other guests. If you
have untrusted PV guests the short term choices are to 1) convert them
to HVM or 2) shield your hypervisor from them by following the
instructions for the 'PV-in-PVH/HVM shim approach' (where currently for
Xen 4.8 only PV-in-HVM is relevant).

There's still a pending security update for Stretch to address the
previous XSA (up to 251), and it seems best to piggyback on that put
some guidance and information for users in there as well.

If you use IRC, you can also join #debian-xen on OFTC if you want, to
discuss things. There's a bunch of people there sharing information and
strategies about what to do with their debian systems.
>> Since this has been reported multiple times already, and upstream has
>> bumped it to 64, my verdict would be:
>>
>> * Bump default to 64 already like upstream did in a later version.
>> * Properly document this issue in NEWS.Debian and also mention the
>> option with documentation in the template grub config file, so
there's a
>> bigger chance users who run unusual big numbers of disks/nics/cpus/etc
>> will find it.
>>
>> ...so we also better accomodate users who are using newer kernels in
the
>> domU with blk-mq, and prevent them from wasting too much time and
>> getting frustrated for no reason.
>>
>> I wouldn't be comfortable with bumping it above the current latest
>> greatest upstream default, since it would mean we would need to keep a
>> patch in later versions.
>>
>> I'll prepare a patch to bump the default to 64 in 4.8, taking
changes
>> from the upstream patch. I probably have to ask upstream (Juergen
Gross)
>> why the commit that was referenced earlier bumps the default without
>> mentioning it in the commit message.
> 
> Thanks, 64 should be a good start.  If there are still problems
> reported with that it can be reconsidered.
Hans