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-ow...@netbsd.org <tech-kern-ow...@netbsd.org> On Behalf Of Emmanuel Dreyfus Sent: Tuesday, October 16, 2018 19:19 To: Terry Moore <t...@mcci.com> Cc: tech-kern@netbsd.org Subject: Re: Reboot resistant USB bug Terry Moore <t...@mcci.com> 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 m...@netbsd.org