Messages in this thread |  | | Date | Tue, 4 Feb 2020 14:25:47 -0800 | From | "Luck, Tony" <> | Subject | What should we do with match_option()? |
| |
Back at the beginning of 2018 David Woodhouse added the inline function match_option() to aid is parsing boot arguments:
da285121560e ("x86/spectre: Add boot time option to select Spectre v2 mitigation")
More recently PeterZ used match_option() in some pseudo-code to help get the split-lock patches un-jammed. I cleaned that up a bit and the patch is now sitting in TIP ready for the next merge window.
But Boris noticed that I'd copy/pasted the inline function defintion, and I promised to look at resolving the duplication.
My first instinct was to just delete both instances from ".c" files and move it to <linux/string.h>. But net/netfilter/xt_dccp.c has its own function with this name (that does something different).
So I looked a bit more closely at what it actually does ... and now I'm not really sure what problem it is solving.
The issue seems to be that cmdline_find_option() might truncate the value of the option string to fit in the user supplied buffer. If that happens, the value in the buffer is guaranteed NUL terminated and cmdline_find_option() returns the length of the full string.
match_option() checks to see if that return value matches the length of the option being checked, and fails if it doesn't match. Which prevents the truncated string from giving a false match against the option string being checked.
But this seems to be a belt, braces (USA=suspenders) and stapling the waistband of trousers (USA=pants) to your body approach.
If the user supplies a large enough buffer to cmdline_find_option() for any of the legal options Then the resulting "arg" will not be truncated for anything legal. So we should be able to just use "strcmp()" to see which of the options is matched.
So should we promote match_option() to <linux/string.h>? Or drop it and just use strcmp() instead?
-Tony
|  |