Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers
On 2020-01-09 09:27, David Hobach wrote: I can confirm the issue for that chipset. Maybe the firmware loading fails, because it's not shipped with the kernel? I don't know... Ah... https://www.startpage.com/do/dsearch?query=uPD720202+firmware --> https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/ Thanks for the references! I'll have to check this out this weekend. So possibly it claims to have the firmware in the EEPROM, but it in fact doesn't and requires it from the kernel. It was my understanding that the setpci statements in my original email say there is no EEPROM/BIOS on the card, but then your references say that I should have been using the "f6.w" argument for that. I'll have to try and see this "f6.w" parameter returns (e.g. setpci -s 00:0[x].0 f6.w ) I'm just learning about this setpci command that I had never heard of before this problem forced me to investigate. Your referenced blog eventually landed me here: http://billauer.co.il/blog/2015/11/renesas-rom-setpci/ Some good information on using this setpci command can be found there. I guess I'll need to spend some time reading up on this, since I have been very interested in how to go about reading and validating EPROMS and BIOS lately, but didn't know quite where to start. Not sure why yours ever worked then. I just got mine, so I can't claim that. Maybe I'll try the stuff mentioned in the blog post. It definitely did work, as I had my system so that whenever I was ready to shutdown, I just clicked on a desktop icon and my scripts found all non-running AppVM that had not yet been backed up, and it would automatically kick off a job to back up those VMs to the sys-usb attached device, and then shut itself down. It made it very easy for my wife that way. But then after some kernel update it just stopped working. I don't know which update killed it, and if I did, I would certainly go look to see if there were drivers in that package prior to that specific update. In hind sight I should have been much more proactive when it first stopped working, but somehow life got in the way. Now that I have some loader software, that you kindly pointed me to, I'll have to look at some of the Live-CD's that previously worked with the card in the past, to see if I can steal a copy of the drivers from one of them. I don't remember specifically which ones worked other than I do remember that one of the prior versions of the Tor Live-cd's did work. Many thanks! I now have something to try out and experiment with. Steve -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ac761e7d-6a8d-2809-4db3-d16af7c9f836%40jhuapl.edu.
Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers
On 1/10/20 10:27 AM, David Hobach wrote: On 1/9/20 3:27 PM, David Hobach wrote: https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/ I tested that after passing the device to a VM via IOMMU. It did work and even survived a reboot (without power off though). Disadvantage here: An attacker may modify the ROM and then use DMA during the boot process to do whatever he wants. But that unfortunately applies to many PCIE devices. It's also an attack quite sensitive to timing. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/41f8b39a-828b-8b91-a853-f73fb8c35e1e%40hackingthe.net. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers
On 1/9/20 3:27 PM, David Hobach wrote: https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/ I tested that after passing the device to a VM via IOMMU. It did work and even survived a reboot (without power off though). I found the firmware inside an extractable executable (7z) of the CD that came with it. It was ~13K and called UPDATE.rom. Good luck with your devices! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/89a818da-ae44-d3c7-f10d-54283fe5ac0d%40hackingthe.net. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers
On 1/7/20 11:58 PM, Steve Coleman wrote: A number of months ago I was happily backing up my system at home using my sys-usb with a dedicated USB controller that worked right out of the box. I didn't need any drivers or anything special. It just worked. Then something happened, likely during an update, which could be like 6 months ago, so I switched back to using dom0 for my updates until I could find the time to look into it. It appeared to me that the USB controller was simply malfunctioning, so I searched for a new card from a different manufacturer which claimed it had native Linux support. But after installing this new card and booting up qubes, nothing. The new card didn't work either. Booting other OS's both cards work just fine. But with qubes neither one works, and as luck would have it both cards have chip-sets from Renesas (uPD720201 uPD720202). I know that I have received a couple of qubes-vm kernel updates over that time, and I can't say for certain which one broke it, but it appears that other people on some other OS's are also having some similar issues: e.g. circa 2018-05-05 https://bugzilla.kernel.org/show_bug.cgi?id=199627 and in 2016 there was a patch to xhci-pci https://lore.kernel.org/patchwork/patch/686290/ and some more recent indecision and push back: https://lore.kernel.org/linux-usb/cancmjzdqx6-+nagebbiym+1czs6jfmop9bm5uk4zup_mw5a...@mail.gmail.com/ https://lore.kernel.org/linux-usb/20191106083843.1718437-2-vk...@kernel.org/ So my question to this forum is; Short of buying yet another "new" USB card and taking a chance of getting the exact same flunky Renesas chipset, what other options are there for resolving this? It seems Kernel.org/linux-usb isn't exactly making haste in fixing this issue, and reverting back to an older and less secure qubes-vm kernel would be a definite mistake given some recent vulnerabilities. Thoughts? Do I need to trash them and just move on? I do have one that is working in my machine here at work, but I'll have to disassemble it to find out what brand/model number it is. I hate breaking tamper seals if I can avoid it. Thanks, Steve My hardware info: $ sudo dmesg | grep xhci [ 16.516802] xhci_hcd :00:07.0: xHCI Host Controller [ 16.516893] xhci_hcd :00:07.0: new USB bus registered, assigned bus number 2 [ 26.517096] xhci_hcd :00:07.0: can't setup: -110 [ 26.517199] xhci_hcd :00:07.0: USB bus 2 deregistered [ 26.520823] xhci_hcd :00:07.0: init :00:07.0 fail, -110 [ 26.520857] xhci_hcd: probe of :00:07.0 failed with error -110 [ 26.522239] xhci_hcd :00:08.0: xHCI Host Controller [ 26.522332] xhci_hcd :00:08.0: new USB bus registered, assigned bus number 2 [ 36.522522] xhci_hcd :00:08.0: can't setup: -110 [ 36.522567] xhci_hcd :00:08.0: USB bus 2 deregistered [ 36.524235] xhci_hcd :00:08.0: init :00:08.0 fail, -110 [ 36.524268] xhci_hcd: probe of :00:08.0 failed with error -110 $ lspci ... 00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) I can confirm the issue for that chipset. Maybe the firmware loading fails, because it's not shipped with the kernel? I don't know... Ah... https://www.startpage.com/do/dsearch?query=uPD720202+firmware --> https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/ So possibly it claims to have the firmware in the EEPROM, but it in fact doesn't and requires it from the kernel. Not sure why yours ever worked then. I just got mine, so I can't claim that. Maybe I'll try the stuff mentioned in the blog post. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/32f441ad-e5eb-0eb4-b58c-f94942036e74%40hackingthe.net. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Renesas uPD720202 uPD720201 usb controllers
A number of months ago I was happily backing up my system at home using my sys-usb with a dedicated USB controller that worked right out of the box. I didn't need any drivers or anything special. It just worked. Then something happened, likely during an update, which could be like 6 months ago, so I switched back to using dom0 for my updates until I could find the time to look into it. It appeared to me that the USB controller was simply malfunctioning, so I searched for a new card from a different manufacturer which claimed it had native Linux support. But after installing this new card and booting up qubes, nothing. The new card didn't work either. Booting other OS's both cards work just fine. But with qubes neither one works, and as luck would have it both cards have chip-sets from Renesas (uPD720201 uPD720202). I know that I have received a couple of qubes-vm kernel updates over that time, and I can't say for certain which one broke it, but it appears that other people on some other OS's are also having some similar issues: e.g. circa 2018-05-05 https://bugzilla.kernel.org/show_bug.cgi?id=199627 and in 2016 there was a patch to xhci-pci https://lore.kernel.org/patchwork/patch/686290/ and some more recent indecision and push back: https://lore.kernel.org/linux-usb/cancmjzdqx6-+nagebbiym+1czs6jfmop9bm5uk4zup_mw5a...@mail.gmail.com/ https://lore.kernel.org/linux-usb/20191106083843.1718437-2-vk...@kernel.org/ So my question to this forum is; Short of buying yet another "new" USB card and taking a chance of getting the exact same flunky Renesas chipset, what other options are there for resolving this? It seems Kernel.org/linux-usb isn't exactly making haste in fixing this issue, and reverting back to an older and less secure qubes-vm kernel would be a definite mistake given some recent vulnerabilities. Thoughts? Do I need to trash them and just move on? I do have one that is working in my machine here at work, but I'll have to disassemble it to find out what brand/model number it is. I hate breaking tamper seals if I can avoid it. Thanks, Steve My hardware info: $ sudo dmesg | grep xhci [ 16.516802] xhci_hcd :00:07.0: xHCI Host Controller [ 16.516893] xhci_hcd :00:07.0: new USB bus registered, assigned bus number 2 [ 26.517096] xhci_hcd :00:07.0: can't setup: -110 [ 26.517199] xhci_hcd :00:07.0: USB bus 2 deregistered [ 26.520823] xhci_hcd :00:07.0: init :00:07.0 fail, -110 [ 26.520857] xhci_hcd: probe of :00:07.0 failed with error -110 [ 26.522239] xhci_hcd :00:08.0: xHCI Host Controller [ 26.522332] xhci_hcd :00:08.0: new USB bus registered, assigned bus number 2 [ 36.522522] xhci_hcd :00:08.0: can't setup: -110 [ 36.522567] xhci_hcd :00:08.0: USB bus 2 deregistered [ 36.524235] xhci_hcd :00:08.0: init :00:08.0 fail, -110 [ 36.524268] xhci_hcd: probe of :00:08.0 failed with error -110 $ lspci ... 00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) 00:08.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) Both controllers are using similar chipsets... > setpci -v -s 00:07.0 f0.l :00:07.0 @f0 = > setpci -v -s 00:07.0 ec.l :00:07.0 @ec = > setpci -v -s 00:08.0 ec.l :00:08.0 @ec = > setpci -v -s 00:08.0 f0.l :00:08.0 @f0 = Hmmm, no bios I can flash... > sudo lspci -vvv 00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI]) Physical Slot: 7 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [a0] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (downgraded),
