RE: Reboot resistant USB bug

["Terry Moore" <tmm%mcci.com@localhost>]

Your code looks like a change to the core USB stack. You're using a
get-descriptor failure to trigger a stuff. If I'm right about where the
change is located, at that layer, the code has no idea if that failure might
be expected. You're just substituting a value. You don't actually know that
the device is the device you think it is, because you don't know if someone
put you to sleep, and swapped devices on that port, and rebooted.

Your fix is fine for a private fix, but if I understand it correctly it
won't do the right thing for the general case.

--Terry 

-----Original Message-----
From: tech-kern-owner%NetBSD.org@localhost <tech-kern-owner%NetBSD.org@localhost> On Behalf Of
Emmanuel Dreyfus
Sent: Tuesday, October 16, 2018 19:19
To: Terry Moore <tmm%mcci.com@localhost>
Cc: tech-kern%netbsd.org@localhost
Subject: Re: Reboot resistant USB bug

Terry Moore <tmm%mcci.com@localhost> wrote:

> Also, some descriptor-gets will normally fail, and it's important to pass
> the failure to the caller.  So I believe that your fix will have
unforeseen
> side-effects.

Well, here the chip documentation states the USB descriptors are
immutable. I used the values from that documentation to fake them once
they get corrupted. How can this go wrong?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost