linux-kernel - Re: [PATCH v2] platform/x86: thinkpad_acpi: Switch to common use of attributes

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: <YVBaQAFVX1CeQUPE@kroah.com>
Date:   Sun, 26 Sep 2021 13:32:16 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Len Baker <len.baker@....com>
Cc:     Henrique de Moraes Holschuh <hmh@....eng.br>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        ibm-acpi-devel@...ts.sourceforge.net,
        platform-driver-x86@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] platform/x86: thinkpad_acpi: Switch to common use of
 attributes

On Sun, Sep 26, 2021 at 01:19:08PM +0200, Len Baker wrote:
> As noted in the "Deprecated Interfaces, Language Features, Attributes,
> and Conventions" documentation [1], size calculations (especially
> multiplication) should not be performed in memory allocator (or similar)
> function arguments due to the risk of them overflowing. This could lead
> to values wrapping around and a smaller allocation being made than the
> caller was expecting. Using those allocations could lead to linear
> overflows of heap memory and other misbehaviors.
> 
> So, to avoid open-coded arithmetic in the kzalloc() call inside the
> create_attr_set() function the code must be refactored. Using the
> struct_size() helper is the fast solution but it is better to switch
> this code to common use of attributes.
> 
> Then, remove all the custom code to manage hotkey attributes and use the
> attribute_group structure instead, refactoring the code accordingly.
> Also, to manage the optional hotkey attributes (hotkey_tablet_mode and
> hotkey_radio_sw) use the is_visible callback from the same structure.
> 
> Moreover, now the hotkey_init_tablet_mode() function never returns a
> negative number. So, the check after the call can be safely removed.
> 
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
> 
> Suggested-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Len Baker <len.baker@....com>
> ---
> Hi,
> 
> Following the suggestions made by Greg I have switch the code to common
> use of attributes. However this code is untested. If someone could test
> it would be great.

Much better, thanks.

But, I have a few questions here:

> @@ -3161,9 +3106,7 @@ static void hotkey_exit(void)
>  	hotkey_poll_stop_sync();
>  	mutex_unlock(&hotkey_mutex);
>  #endif
> -
> -	if (hotkey_dev_attributes)
> -		delete_attr_set(hotkey_dev_attributes, &tpacpi_pdev->dev.kobj);
> +	sysfs_remove_group(&tpacpi_pdev->dev.kobj, &hotkey_attr_group);

Why do you have to manually add/remove these groups still?

A huge hint that something is going wrong is when you have to call a
sysfs_*() call from within a driver.  There should be proper driver_*()
calls for you instead to get the job done.

As this is a platform device, why not set the dev_groups variable in the
platform_driver field so that these attribute groups get added and
removed automatically?

An example commit to look at that shows how this was converted for one
driver is 5bd08a4ae3d0 ("platform: x86: hp-wmi: convert platform driver
to use dev_groups").  See if that helps here as well.

thanks,

greg k-h