Crash in usb_keyboard

Crash in usb_keyboard

[Pavel Roskin]

Hello!

Running "terminal_input.usb_keyboard" crashed GRUB (or qemu it's running
in).  It turns out we never check if usbdev in term/usb_keyboard.c is
not NULL.  It is NULL if no USB host controllers have been detected.

I'm not sure if we even want to call grub_term_register_input() if no
USB keyboard is present.

-- 
Regards,
Pavel Roskin

Re: Crash in usb_keyboard

[Robert Millan]

On Mon, Apr 27, 2009 at 11:55:10PM -0400, Pavel Roskin wrote:
> Hello!
> 
> Running "terminal_input.usb_keyboard" crashed GRUB (or qemu it's running
> in).  It turns out we never check if usbdev in term/usb_keyboard.c is
> not NULL.  It is NULL if no USB host controllers have been detected.
> 
> I'm not sure if we even want to call grub_term_register_input() if no
> USB keyboard is present.

What if a keyboard is not present, but plugged in later?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Crash in usb_keyboard

[Pavel Roskin]

On Sat, 2009-05-02 at 13:39 +0200, Robert Millan wrote:
> On Mon, Apr 27, 2009 at 11:55:10PM -0400, Pavel Roskin wrote:
> > Hello!
> > 
> > Running "terminal_input.usb_keyboard" crashed GRUB (or qemu it's running
> > in).  It turns out we never check if usbdev in term/usb_keyboard.c is
> > not NULL.  It is NULL if no USB host controllers have been detected.
> > 
> > I'm not sure if we even want to call grub_term_register_input() if no
> > USB keyboard is present.
> 
> What if a keyboard is not present, but plugged in later?

If we add support for USB hotplug, then we'll take care of it.  I don't
think GRUB will support interrupts, but it may get support for timers
that would rescan the USB tree periodically.

When USB hotplug is not supported, it doesn't really matter if
terminal_input.usb_keyboard succeeds of fails in absence of a USB
keyboard.

By the way, we need to handle the case of multiple keyboards.  That
would automatically take care of the zero keyboards.

It looks like the current code can match non-keyboards.

For my keyboard, "lsusb -v" gives:

  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
...
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None

The existing code doesn't check interfaces.

-- 
Regards,
Pavel Roskin

Re: Crash in usb_keyboard

[Robert Millan]

On Sun, May 03, 2009 at 12:25:31AM -0400, Pavel Roskin wrote:
> On Sat, 2009-05-02 at 13:39 +0200, Robert Millan wrote:
> > On Mon, Apr 27, 2009 at 11:55:10PM -0400, Pavel Roskin wrote:
> > > Hello!
> > > 
> > > Running "terminal_input.usb_keyboard" crashed GRUB (or qemu it's running
> > > in).  It turns out we never check if usbdev in term/usb_keyboard.c is
> > > not NULL.  It is NULL if no USB host controllers have been detected.
> > > 
> > > I'm not sure if we even want to call grub_term_register_input() if no
> > > USB keyboard is present.
> > 
> > What if a keyboard is not present, but plugged in later?
> 
> If we add support for USB hotplug, then we'll take care of it.  I don't
> think GRUB will support interrupts, but it may get support for timers
> that would rescan the USB tree periodically.

Our alternative to interrupts has so far been polling.  Is it viable to
poll for USB keyboards every time a read is attempted?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Crash in usb_keyboard

[Pavel Roskin]

On Sun, 2009-05-03 at 17:56 +0200, Robert Millan wrote:

> Our alternative to interrupts has so far been polling.  Is it viable to
> poll for USB keyboards every time a read is attempted?

We can try it.

-- 
Regards,
Pavel Roskin