Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Chuck Zmudzinski]

On 8/24/2021 1:12 PM, Ben Hutchings wrote:
> On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote:
>> On 5/24/2021 3:30 AM, Michael Biebl wrote:
>>> Hi Phillip
>>>
>>> Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:
>>>>> trigger to cold plug all devices.  Both scripts are set -e.  The Xen
>>>>> Virtual Keyboard driver and at least one other driver have always
>>>>> failed
>>>>> to trigger due to having absurdly long modalias, but the error used to
>>>>> be ignored.  The kernel now returns the error to udevadm
>>> So this is a change in behaviour in the kernel?
>>> What happens if you boot the installed system? Does udevadm trigger
>>> fail there as well?
>>>
>>> I feel a bit uneasy changing the udev start script this late in the
>>> release cycle (especially when it appears like covering up an issue
>>> someplace else).
>>>
>>> I'll let Marco make the judgement on this though, as he has the most
>>> experience with those udev udeb start scripts as the original author.
>>>
>>> Michael
>>>
>> After reviewing Philip's message at
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43
>>
>> which seems to point to the root cause of this bug, I can add:
>>
>> On my Xen HVM DomU I see the absurdly long modalias for the Xen
>> Virtual keyboard that seems to be causing this crash in sysfs at
>>
>> /sys/devices/virtual/input/input2/modalias
>>
>> But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would
>> probably not result in an error in the udev script if this was also
>> written as the modalias at /sys/devices/virtual/input/input2/modalias
>>
>> So the Xen virtual keyboard appears more than once in sysfs, and
>> modalias is not the same in the different places. This seems
>> to be a problem.
> They are two different devices, and they should have different
> modaliases.
>
> Linux has code for discovering devices on each kind of bus, including
> virtual buses, and that code creates "bus devices" such as vkbd-0.  At
> this point the kernel doesn't know what the device is capable of.  The
> modalias for a bus device carries some identifying information that can
> be used to select a driver module for it.
>
> The driver does know what the device is capable of, and how to use it.
> It will normally create one or more "class devices" that support a
> particular set of operations; in this case input device operations.
> Class devices typically don't have modaliases, since they don't need
> another layer of drivers on top.  However, for input devices the
> modalias carries information about the device's capabilities.  These
> may trigger loading of the evdev or joydev module.
>
>> I understand the correct way to fix this bug is by modifying the
>> Xxen virtual keyboard (and any other devices that might cause
>> this crash) and not the start-udev script on the netinst
>> installation media, which is so far the only available workaround.
>> Hopefully Xen will accept a fix if we can come up with a fix.
> [...]
>
> I think a proper fix would be one of:
>
> a. If the Xen virtual keyboard driver is advertising capabilities it
>     doesn't have, stop it doing that.
> b. Change the implementation of modalias attributes to allow longer
>     values.
>
> It's not clear to me whether the Xen driver is advertising correctly or
> not.  If it is, then the solution should be b, but that may be too
> disruptive a change to the kernel.  So a reasonable workaround might
> be:
>
> c. Change the input subsystem to limit the length of the
>     capabilities part of the modalias.
>
>
> Ben.
>

So workaround c would not involve disruptions to the kernel or
systemd? Workaround c seems too disruptive for stable to me,
but maybe could go into unstable and eventually into testing.

A problem with the approach of fixing this bug in the Xen
keyboard driver is that the fix must be implemented in the underlying
Dom0 system, which could be almost anything - another Linux distro
or Debian stable or oldstable. Any fix upstream would probably get into
a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
provided as a backport for anyone who is still on oldstable for their
Xen Dom0.

Anyway, I will look into the Xen virtual keyboard capabilities. The
only capability I can think of that would be useful in this context is that
it supports live migration of a VM through some sort of hot-swapping
capability. If it has that capability, a workaround to support it would be
good. But if it does not have that capability or if such a capability is
not needed for a keyboard, then it should probably stop advertising
itself as being able or needing to do that. Ultimately, it is up to Xen to
decide if they are going to make changes to its virtual keyboard.

Chuck