linux-kernel - Re: [PATCH HID 6/7] HID: bpf: Allow to control the connect mask of hid-generic from BPF

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: <20240903055745.GB968953@quokka>
Date: Tue, 3 Sep 2024 15:57:45 +1000
From: Peter Hutterer <peter.hutterer@...-t.net>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Jiri Kosina <jikos@...nel.org>, Vicki Pfau <vi@...rift.com>,
	Shuah Khan <shuah@...nel.org>, Jonathan Corbet <corbet@....net>,
	linux-input@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH HID 6/7] HID: bpf: Allow to control the connect mask of
 hid-generic from BPF

On Tue, Sep 03, 2024 at 01:14:36AM +0900, Benjamin Tissoires wrote:
> We make struct hid_device_id writeable and use the .driver_data field
> of hid-generic as the connect mask.

I think this needs to be spelled out a bit more: for this to work the
driver *must* be hid-generic, otherwise this doesn't work. But I'm a bit
confused why we have a custom fields for force/ignore driver but 
whether the device is connected (and thus uses the driver) is hidden in
an effectively undocumented private field of one specific driver.

Wouldn't it be easier to add another boolean (or enum entry, see my
other comment) to hid_bpf_driver? This way *how* it happens is hidden
from the API as well - you say "hidraw only please" and the kernel does
the rest (through hid-generic or otherwise).

Cheers,
  Peter

> 
> This way, we can control from a HID-BPF program if a device needs to
> be exported through hidraw and/or hid-input mainly.
> 
> This is useful in case we want to have a third party program that directly
> talks to the hidraw node and we don't want regular input events to be
> emitted. This third party program can load a BPF program that instructs
> hid-generic to rebind on the device with hidraw only and then open the
> hidraw node itself.
> 
> When the application is closed, the BPF program is unloaded and the normal
> driver takes back the control of the device.
> 
> Signed-off-by: Benjamin Tissoires <bentiss@...nel.org>
> ---
>  drivers/hid/bpf/hid_bpf_struct_ops.c |  1 +
>  drivers/hid/hid-core.c               | 14 ++++++++------
>  drivers/hid/hid-generic.c            |  5 +++--
>  3 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
> index 1e13a22f73a1..bb755edd02f0 100644
> --- a/drivers/hid/bpf/hid_bpf_struct_ops.c
> +++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
> @@ -80,6 +80,7 @@ static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,
>  		WRITE_RANGE(hid_device, name, true),
>  		WRITE_RANGE(hid_device, uniq, true),
>  		WRITE_RANGE(hid_device, phys, true),
> +		WRITE_RANGE(hid_device_id, driver_data, false),
>  		WRITE_RANGE(hid_bpf_driver, force_driver, false),
>  		WRITE_RANGE(hid_bpf_driver, ignore_driver, false),
>  	};
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 7845f0a789ec..2bd279b23aa4 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2637,15 +2637,17 @@ EXPORT_SYMBOL_GPL(hid_compare_device_paths);
>  
>  static bool hid_check_device_match(struct hid_device *hdev,
>  				   struct hid_driver *hdrv,
> -				   const struct hid_device_id **id)
> +				   struct hid_device_id *id)
>  {
> +	const struct hid_device_id *_id = hid_match_device(hdev, hdrv);
>  	int ret;
>  
> -	*id = hid_match_device(hdev, hdrv);
> -	if (!*id)
> +	if (!_id)
>  		return false;
>  
> -	ret = call_hid_bpf_driver_probe(hdev, hdrv, *id);
> +	memcpy(id, _id, sizeof(*id));
> +
> +	ret = call_hid_bpf_driver_probe(hdev, hdrv, id);
>  	if (ret)
>  		return ret > 0;
>  
> @@ -2662,7 +2664,7 @@ static bool hid_check_device_match(struct hid_device *hdev,
>  
>  static int __hid_device_probe(struct hid_device *hdev, struct hid_driver *hdrv)
>  {
> -	const struct hid_device_id *id;
> +	struct hid_device_id id;
>  	int ret;
>  
>  	if (!hid_check_device_match(hdev, hdrv, &id))
> @@ -2677,7 +2679,7 @@ static int __hid_device_probe(struct hid_device *hdev, struct hid_driver *hdrv)
>  	hdev->driver = hdrv;
>  
>  	if (hdrv->probe) {
> -		ret = hdrv->probe(hdev, id);
> +		ret = hdrv->probe(hdev, &id);
>  	} else { /* default probe */
>  		ret = hid_open_report(hdev);
>  		if (!ret)
> diff --git a/drivers/hid/hid-generic.c b/drivers/hid/hid-generic.c
> index f9db991d3c5a..5cd1f3a79a4b 100644
> --- a/drivers/hid/hid-generic.c
> +++ b/drivers/hid/hid-generic.c
> @@ -64,11 +64,12 @@ static int hid_generic_probe(struct hid_device *hdev,
>  	if (ret)
>  		return ret;
>  
> -	return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> +	return hid_hw_start(hdev, id->driver_data);
>  }
>  
>  static const struct hid_device_id hid_table[] = {
> -	{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, HID_ANY_ID, HID_ANY_ID) },
> +	{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, HID_ANY_ID, HID_ANY_ID),
> +		.driver_data = HID_CONNECT_DEFAULT },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(hid, hid_table);
> 
> -- 
> 2.46.0
>