linux-kernel - Re: chipidea: udc: kernel panic in isr_setup_status

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Aug 2016 19:20:45 +0200
From:   Clemens Gruber <clemens.gruber@...ruber.com>
To:     Peter Chen <hzpeterchen@...il.com>
Cc:     linux-usb@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: chipidea: udc: kernel panic in isr_setup_status_phase

On Mon, Aug 29, 2016 at 06:24:03PM +0800, Peter Chen wrote:
> Would you please measure the voltage of vbus within 1s at below two
> conditions:
> 
> - Just connect cable
> - Just disconnect cable

We found out that there was a problem with our hardware design!

But first, here is the VBUS measurement during cable plug-in.
https://s17.postimg.org/8ba3rgl6n/linux_kernel_panic_usb_otg_vbus_is_yellow.jpg
(The yellow signal is USB_OTG_VBUS, please ignore the red one)
The kernel panic occurs where the slip of paper with the arrow is.
The signal looks normal to me, I don't think VBUS was the problem.

The other theory was a GND problem..
After thorough investigation, we discovered that we connected all
SHIELD pins of the USB micro OTG connector to the protective-earth
ground (GND_PE) with a 1 MOhm resistor and a 1 nF cap in parallel.
We changed that to connect the SHIELD pins to the same internal GND
as the USB signals have and also replaced the 1 MOhm resistor with a
100 Ohm  resistor as seen in the MCIMX6Q-SDB schematics.
Since that change, the error did not appear again! :)

The only signals I never checked are the differential high speed signals
(USB_OTG_DN and USB_OTG_DP) because I don't have the necessary equipment
like active differential probes for very high frequency measurements, ..
Maybe with the connection of the shield to PE, the cable acted as an
antenna and interfered with the high speed signals?
(Although they are differential, so the same noise to both should not
be a problem? It is still a mystery to me, what was really causing it)

--

What do you think about still fixing that kernel panic in case something
similar happens again for other users?
If such a situation occurs, should we only avoid the NULL pointer
dereference or print out an error message and stop the gadget driver?

Regards,
Clemens