All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aleš Nesrsta" <starous@volny.cz>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Fix invalid USB descriptor endless loop.
Date: Wed, 18 Sep 2013 00:06:10 +0200	[thread overview]
Message-ID: <5238D252.40804@volny.cz> (raw)
In-Reply-To: <BBCDB0B9B472124D9EED8CB900AA04CA1F91E92E@corpappl747.corp.saab.se>

Hi Christian,
sorry for delay, I am too busy in last time.

 > Hi,
 >
 > I discovered that on some PC's the USB stack would produce an invalid 
 > descriptor upon query without an error.
 > I don't know why this is the case, maybe broken hardware but I
 > seriously doubt it.
 > GRUB doesn't handle TT's at all, Clearing TT's or resetting them.
 > Maybe thats a case for stuck transactions?
 > The descriptor would contain 0 in length, or atleast the code would
 > think that offset was the length
 > and cause an endless loop.

I have minimal practical experiences with TT's.
Theoretically, AFAIK, it should normally work without special 
intervention - but of course the praxis could be different or I possibly 
missed something important...


> Maybe this type of parsing is completely avoidable but for now I just added a break condition.
> GRUB should not hang on faulty devices.

I cannot comment it (mainly the first sentence) - I am not original 
author of the most of GRUB USB code and this part of usb.c I didn't 
touched/studied yet (with some small exceptions) - I believed it works 
fine...:-)
I have no time currently to think about this situation more deeply, but 
from my point of view, if this situation can really happen and cannot be 
avoided by another way, this patch could be OK.


But it will be very good to know also the reason why the broken 
descriptor is read from device and no another error is indicated.
Which devices are affected? And which descriptor(s) exactly? Are these 
devices working well under Windows? Are affected still the same devices 
and in every case (at every connect)? And on every port of PC? Could you 
send detailed Linux lsusb output of "broken" devices? Or possibly whole 
detailed lsusb output, to be able to see the way how the device is 
connected to USB controller.

BR, Ales


>
> BR,
> Christian
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


  reply	other threads:[~2013-09-17 22:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09  6:22 [PATCH] Fix invalid USB descriptor endless loop Melki Christian (consultant)
2013-09-17 22:06 ` Aleš Nesrsta [this message]
2013-09-18 11:27 ` Vladimir 'φ-coder/phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5238D252.40804@volny.cz \
    --to=starous@volny.cz \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.