| Message ID | 20220222132707.266883-1-krzysztof.kozlowski@canonical.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix kfree() of const memory on setting driver_override | expand |
On 22/02/2022 14.27, Krzysztof Kozlowski wrote: > Hi, > > Drivers still seem to use driver_override incorrectly. Perhaps my old > patch makes sense now? > https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ > > Not tested - please review and test (e.g. by writing to dirver_override > sysfs entry with KASAN enabled). Perhaps it would make sense to update the core code to release using kfree_const(), allowing drivers to set the initial value with kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() will continue to work [but if they kstrdup() a string literal they could be changed to use kstrdup_const]. Rasmus
On 22/02/2022 14:51, Rasmus Villemoes wrote: > On 22/02/2022 14.27, Krzysztof Kozlowski wrote: >> Hi, >> >> Drivers still seem to use driver_override incorrectly. Perhaps my old >> patch makes sense now? >> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ >> >> Not tested - please review and test (e.g. by writing to dirver_override >> sysfs entry with KASAN enabled). > > Perhaps it would make sense to update the core code to release using > kfree_const(), allowing drivers to set the initial value with > kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() > will continue to work [but if they kstrdup() a string literal they could > be changed to use kstrdup_const]. The core here means several buses, so the change would not be that small. However I don't see the reason why "driver_override" is special and should be freed with kfree_const() while most of other places don't use it. The driver_override field definition is here obvious: "char *", so any assignments of "const char *" are logically wrong (although GCC does not warn of this literal string const discarding). Adding kfree_const() is hiding the problem - someone did not read the definition of assigned field. Best regards, Krzysztof
On 2022-02-22 14:06, Krzysztof Kozlowski wrote: > On 22/02/2022 14:51, Rasmus Villemoes wrote: >> On 22/02/2022 14.27, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> Drivers still seem to use driver_override incorrectly. Perhaps my old >>> patch makes sense now? >>> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ >>> >>> Not tested - please review and test (e.g. by writing to dirver_override >>> sysfs entry with KASAN enabled). >> >> Perhaps it would make sense to update the core code to release using >> kfree_const(), allowing drivers to set the initial value with >> kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() >> will continue to work [but if they kstrdup() a string literal they could >> be changed to use kstrdup_const]. > > The core here means several buses, so the change would not be that > small. However I don't see the reason why "driver_override" is special > and should be freed with kfree_const() while most of other places don't > use it. > > The driver_override field definition is here obvious: "char *", so any > assignments of "const char *" are logically wrong (although GCC does not > warn of this literal string const discarding). Adding kfree_const() is > hiding the problem - someone did not read the definition of assigned field. That's not the issue, though, is it? If I take the struct platform_device definition at face value, this should be perfectly valid: static char foo[] = "foo"; pdev->driver_override = &foo; And in fact that's effectively how the direct assignment form works anyway - string literals are static arrays of type char (or wchar_t), *not* const char, however trying to modify them is undefined behaviour. There's a big difference between "non-const" and "kfree()able", and AFAICS there's no obvious clue that the latter is actually a requirement. Cheers, Robin.
On 23/02/2022 15:04, Robin Murphy wrote: > On 2022-02-22 14:06, Krzysztof Kozlowski wrote: >> On 22/02/2022 14:51, Rasmus Villemoes wrote: >>> On 22/02/2022 14.27, Krzysztof Kozlowski wrote: >>>> Hi, >>>> >>>> Drivers still seem to use driver_override incorrectly. Perhaps my old >>>> patch makes sense now? >>>> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ >>>> >>>> Not tested - please review and test (e.g. by writing to dirver_override >>>> sysfs entry with KASAN enabled). >>> >>> Perhaps it would make sense to update the core code to release using >>> kfree_const(), allowing drivers to set the initial value with >>> kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() >>> will continue to work [but if they kstrdup() a string literal they could >>> be changed to use kstrdup_const]. >> >> The core here means several buses, so the change would not be that >> small. However I don't see the reason why "driver_override" is special >> and should be freed with kfree_const() while most of other places don't >> use it. >> >> The driver_override field definition is here obvious: "char *", so any >> assignments of "const char *" are logically wrong (although GCC does not >> warn of this literal string const discarding). Adding kfree_const() is >> hiding the problem - someone did not read the definition of assigned field. > > That's not the issue, though, is it? If I take the struct > platform_device definition at face value, this should be perfectly valid: > > static char foo[] = "foo"; > pdev->driver_override = &foo; Yes, that's not the issue. It's rather about the interface. By convention we do not modify string literals but "char *driver_override" indicates that this is modifiable memory. I would argue that it even means that ownership is passed. Therefore passing string literal to "char *driver_override" is wrong from logical point of view. Plus, as you mentioned later, can lead to undefined behavior. > > And in fact that's effectively how the direct assignment form works > anyway - string literals are static arrays of type char (or wchar_t), > *not* const char, however trying to modify them is undefined behaviour. > > There's a big difference between "non-const" and "kfree()able", and > AFAICS there's no obvious clue that the latter is actually a requirement. Then maybe kfreeable should be made a requirement? Or at least clearly documented? Best regards, Krzysztof
On 2022-02-23 14:22, Krzysztof Kozlowski wrote: > On 23/02/2022 15:04, Robin Murphy wrote: >> On 2022-02-22 14:06, Krzysztof Kozlowski wrote: >>> On 22/02/2022 14:51, Rasmus Villemoes wrote: >>>> On 22/02/2022 14.27, Krzysztof Kozlowski wrote: >>>>> Hi, >>>>> >>>>> Drivers still seem to use driver_override incorrectly. Perhaps my old >>>>> patch makes sense now? >>>>> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ >>>>> >>>>> Not tested - please review and test (e.g. by writing to dirver_override >>>>> sysfs entry with KASAN enabled). >>>> >>>> Perhaps it would make sense to update the core code to release using >>>> kfree_const(), allowing drivers to set the initial value with >>>> kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() >>>> will continue to work [but if they kstrdup() a string literal they could >>>> be changed to use kstrdup_const]. >>> >>> The core here means several buses, so the change would not be that >>> small. However I don't see the reason why "driver_override" is special >>> and should be freed with kfree_const() while most of other places don't >>> use it. >>> >>> The driver_override field definition is here obvious: "char *", so any >>> assignments of "const char *" are logically wrong (although GCC does not >>> warn of this literal string const discarding). Adding kfree_const() is >>> hiding the problem - someone did not read the definition of assigned field. >> >> That's not the issue, though, is it? If I take the struct >> platform_device definition at face value, this should be perfectly valid: >> >> static char foo[] = "foo"; >> pdev->driver_override = &foo; > > > Yes, that's not the issue. It's rather about the interface. By > convention we do not modify string literals but "char *driver_override" > indicates that this is modifiable memory. I would argue that it even > means that ownership is passed. Therefore passing string literal to > "char *driver_override" is wrong from logical point of view. > > Plus, as you mentioned later, can lead to undefined behavior. But does anything actually need to modify a driver_override string? I wouldn't have thought so. I see at least two buses that *do* define theirs as const char *, but still assume to kfree() them. >> And in fact that's effectively how the direct assignment form works >> anyway - string literals are static arrays of type char (or wchar_t), >> *not* const char, however trying to modify them is undefined behaviour. >> >> There's a big difference between "non-const" and "kfree()able", and >> AFAICS there's no obvious clue that the latter is actually a requirement. > > Then maybe kfreeable should be made a requirement? Or at least clearly > documented? Indeed, there's clearly some room for improvement still. And I'm not suggesting that these changes aren't already sensible as they are, just that the given justification seems a little unfair :) Even kfree_const() can't help if someone has put their string in the middle of some larger block of kmalloc()ed memory, so perhaps encouraging a dedicated setter function rather than just exposing a raw string pointer is the ideal solution in the long term. Cheers, Robin.
On 23/02/2022 16:08, Robin Murphy wrote: > On 2022-02-23 14:22, Krzysztof Kozlowski wrote: >> On 23/02/2022 15:04, Robin Murphy wrote: >>> On 2022-02-22 14:06, Krzysztof Kozlowski wrote: >>>> On 22/02/2022 14:51, Rasmus Villemoes wrote: >>>>> On 22/02/2022 14.27, Krzysztof Kozlowski wrote: >>>>>> Hi, >>>>>> >>>>>> Drivers still seem to use driver_override incorrectly. Perhaps my old >>>>>> patch makes sense now? >>>>>> https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ >>>>>> >>>>>> Not tested - please review and test (e.g. by writing to dirver_override >>>>>> sysfs entry with KASAN enabled). >>>>> >>>>> Perhaps it would make sense to update the core code to release using >>>>> kfree_const(), allowing drivers to set the initial value with >>>>> kstrdup_const(). Drivers that currently use kstrdup() or kasprintf() >>>>> will continue to work [but if they kstrdup() a string literal they could >>>>> be changed to use kstrdup_const]. >>>> >>>> The core here means several buses, so the change would not be that >>>> small. However I don't see the reason why "driver_override" is special >>>> and should be freed with kfree_const() while most of other places don't >>>> use it. >>>> >>>> The driver_override field definition is here obvious: "char *", so any >>>> assignments of "const char *" are logically wrong (although GCC does not >>>> warn of this literal string const discarding). Adding kfree_const() is >>>> hiding the problem - someone did not read the definition of assigned field. >>> >>> That's not the issue, though, is it? If I take the struct >>> platform_device definition at face value, this should be perfectly valid: >>> >>> static char foo[] = "foo"; >>> pdev->driver_override = &foo; >> >> >> Yes, that's not the issue. It's rather about the interface. By >> convention we do not modify string literals but "char *driver_override" >> indicates that this is modifiable memory. I would argue that it even >> means that ownership is passed. Therefore passing string literal to >> "char *driver_override" is wrong from logical point of view. >> >> Plus, as you mentioned later, can lead to undefined behavior. > > But does anything actually need to modify a driver_override string? I > wouldn't have thought so. I see at least two buses that *do* define > theirs as const char *, but still assume to kfree() them. I think the drivers/clk/imx/clk-scu.c (fixed here) does not actually need it. It uses the feature to create multiple platform devices for each clock, with unique names matching the clock (e.g. pwm0_clk, pwm1_clk) and then bind all them via common clock driver. It looks therefore like something for convenience of debugging or going through sysfs devices. Removal of driver_override from such drivers is a bit too much here, because I would not be able to test it. > >>> And in fact that's effectively how the direct assignment form works >>> anyway - string literals are static arrays of type char (or wchar_t), >>> *not* const char, however trying to modify them is undefined behaviour. >>> >>> There's a big difference between "non-const" and "kfree()able", and >>> AFAICS there's no obvious clue that the latter is actually a requirement. >> >> Then maybe kfreeable should be made a requirement? Or at least clearly >> documented? > > Indeed, there's clearly some room for improvement still. And I'm not > suggesting that these changes aren't already sensible as they are, just > that the given justification seems a little unfair :) Yeah, maybe also my "const" in the title and commit is not accurate. I think that literal strings are part of .rodata (and objdump confirm) thus are considered const. > Even kfree_const() can't help if someone has put their string in the > middle of some larger block of kmalloc()ed memory, so perhaps > encouraging a dedicated setter function rather than just exposing a raw > string pointer is the ideal solution in the long term. Best regards, Krzysztof
Hi, Drivers still seem to use driver_override incorrectly. Perhaps my old patch makes sense now? https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ Not tested - please review and test (e.g. by writing to dirver_override sysfs entry with KASAN enabled). Dependencies ============ Patches are independent. Best regards, Krzysztof Krzysztof Kozlowski (3): clk: imx: scu: fix kfree() of const memory on setting driver_override slimbus: qcom-ngd: fix kfree() of const memory on setting driver_override rpmsg: fix kfree() of const memory on setting driver_override drivers/clk/imx/clk-scu.c | 6 +++++- drivers/rpmsg/rpmsg_internal.h | 12 ++++++++++-- drivers/rpmsg/rpmsg_ns.c | 13 +++++++++++-- drivers/slimbus/qcom-ngd-ctrl.c | 9 ++++++++- 4 files changed, 34 insertions(+), 6 deletions(-)