linux-kernel - Re: [PATCH v1] usb: core: Add boot delay for DH34 board in restore mode

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]

Message-ID: <d3b12542-4919-45e7-b2a5-28742a6c7943@rowland.harvard.edu>
Date: Thu, 6 Mar 2025 08:29:08 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Jiayi Li <lijiayi@...inos.cn>
Cc: gregkh@...uxfoundation.org, stefan.eichenberger@...adex.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	jiayi_dec@....com
Subject: Re: [PATCH v1] usb: core: Add boot delay for DH34 board in restore
 mode

On Thu, Mar 06, 2025 at 02:17:49PM +0800, Jiayi Li wrote:
> On certain DH34-model motherboards, USB keyboards may fail to respond
> during the restore mode confirmation prompt due to the usbhid driver
> not being fully initialized when device registration occurs.

Why does that make any difference?  The driver core will probe the 
usbhid driver when it is fully registered (assuming the keyboard device 
hasn't been bound to a different driver in the meantime).

>  This
> results in inability to input 'y'/'n' confirmation.
> 
> Detect this scenario by:
> 1. Checking DMI_BOARD_NAME for "DH34" substring
> 2. Verifying "restore" in kernel command line
> 
> Introduce a 200ms delay before device registration when both conditions
> are met. This allows sufficient time for the usbhid driver to properly
> initialize before user interaction is required.

Why does delaying device registration help?  In theory it should make 
things worse: When user interaction is required, the keyboard device 
won't even be registered yet, let alone bound to the usbhid driver.  

Furthermore, your patch delays registration of _all_ devices, not just 
the keyboard device.  This will slow down the restore-mode boot 
procedure considerably.

It sounds like what you really need to do is delay the user interaction, 
leaving the device and driver initialization and registration unchanged.

Alan Stern

> Signed-off-by: Jiayi Li <lijiayi@...inos.cn>
> ---
>  drivers/usb/core/hub.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index a76bb50b6202..b81b518f438b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -36,6 +36,7 @@
>  #include <linux/bitfield.h>
>  #include <linux/uaccess.h>
>  #include <asm/byteorder.h>
> +#include <linux/dmi.h>
>  
>  #include "hub.h"
>  #include "phy.h"
> @@ -2610,6 +2611,7 @@ static void set_usb_port_removable(struct usb_device *udev)
>  int usb_new_device(struct usb_device *udev)
>  {
>  	int err;
> +	const char *board_name;
>  
>  	if (udev->parent) {
>  		/* Initialize non-root-hub device wakeup to disabled;
> @@ -2656,6 +2658,17 @@ int usb_new_device(struct usb_device *udev)
>  	/* check whether the hub or firmware marks this port as non-removable */
>  	set_usb_port_removable(udev);
>  
> +	/* get board manufacturer information (DMI_BOARD_VENDOR) */
> +	board_name = dmi_get_system_info(DMI_BOARD_NAME);
> +
> +	/* In order to load the usbhid driver on a specific model motherboards
> +	 * before the restore mode confirmation, add 200ms of latancy.
> +	 */
> +	if (board_name && strstr(board_name, "DH34") &&
> +		(strstr(saved_command_line, "restore") != NULL))
> +		msleep(200);
> +
> +
>  	/* Register the device.  The device driver is responsible
>  	 * for configuring the device and invoking the add-device
>  	 * notifier chain (used by usbfs and possibly others).
> -- 
> 2.47.1
>