From: Ingo Molnar <mingo@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Justin Stitt <justinstitt@google.com>,
Steve Wahl <steve.wahl@hpe.com>,
Mike Travis <mike.travis@hpe.com>,
Dimitri Sivanich <dimitri.sivanich@hpe.com>,
Russ Anderson <russ.anderson@hpe.com>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3] x86/platform/uv: refactor deprecated strcpy and strncpy
Date: Wed, 6 Sep 2023 16:09:01 +0200 [thread overview]
Message-ID: <ZPiH/ds9oeimXDdb@gmail.com> (raw)
In-Reply-To: <bce762af-0da7-bb5e-1580-b42803c183f6@redhat.com>
* Hans de Goede <hdegoede@redhat.com> wrote:
> Hi Ingo,
>
> On 9/6/23 14:10, Ingo Molnar wrote:
> >
> > * Justin Stitt <justinstitt@google.com> wrote:
> >
> >> Both `strncpy` and `strcpy` are deprecated for use on NUL-terminated
> >> destination strings [1].
> >>
> >> We can see that `arg` and `uv_nmi_action` are expected to be
> >> NUL-terminated strings due to their use within `strcmp()` and format
> >> strings respectively.
> >>
> >> With this in mind, a suitable replacement is `strscpy` [2] due to the
> >> fact that it guarantees NUL-termination on its destination buffer
> >> argument which is _not_ the case for `strncpy` or `strcpy`!
> >>
> >> In this case, we can drop both the forced NUL-termination and the `... -1` from:
> >> | strncpy(arg, val, ACTION_LEN - 1);
> >> as `strscpy` implicitly has this behavior.
> >>
> >> Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings[1]
> >> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
> >> Link: https://github.com/KSPP/linux/issues/90
> >> Cc: linux-hardening@vger.kernel.org
> >> Signed-off-by: Justin Stitt <justinstitt@google.com>
> >
> >> arch/x86/platform/uv/uv_nmi.c | 7 +++----
> >> 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > Note that this commit is already upstream:
> >
> > 1e6f01f72855 ("x86/platform/uv: Refactor code using deprecated strcpy()/strncpy() interfaces to use strscpy()")
> >
> > Below is the delta your v3 patch has compared to what is upstream - is it
> > really necessary to open code it, instead of using strnchrnul() as your
> > original patch did? Am I missing anything here?
>
> The new version is a result of a review from my because IMHO:
>
> strscpy(arg, val, strnchrnul(val, sizeof(arg)-1, '\n') - val + 1);
>
> Is really unreadable / really hard to reason about if
> this is actually correct and does not contain any
> of by 1 bugs.
>
> Note that the diff of v3 compared to the code before v2 landed is
> actually smaller now and actually matches the subject of:
> "refactor deprecated strcpy and strncpy"
>
> Where as v2 actually touches more code / refactor things
> which fall outside of a "one change per patch" approach.
> The:
>
> p = strchr(arg, '\n');
> if (p)
> *p = '\0';
>
> was already there before v2 landed.
>
> I also suggested to do a follow up patch to change things to:
>
> strscpy(arg, val, sizeof(arg));
> p = strchrnul(arg, '\n');
> *p = '\0';
>
> Which IMHO is much more readable then what has landed
> now. But since v2 has already landed I guess the best
> thing is just to stick with what we have upstream now...
Well, how about we do a delta patch with all the changes
you suggested? I'm all for readability.
Thanks,
Ingo
next prev parent reply other threads:[~2023-09-06 14:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 21:54 [PATCH v3] x86/platform/uv: refactor deprecated strcpy and strncpy Justin Stitt
2023-09-06 11:42 ` Hans de Goede
2023-09-06 12:10 ` Ingo Molnar
2023-09-06 12:16 ` Hans de Goede
2023-09-06 13:30 ` Andy Shevchenko
2023-09-06 14:09 ` Ingo Molnar [this message]
2023-09-06 15:07 ` Steve Wahl
2023-09-13 15:12 ` Hans de Goede
2023-09-14 6:30 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZPiH/ds9oeimXDdb@gmail.com \
--to=mingo@kernel.org \
--cc=andy@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dimitri.sivanich@hpe.com \
--cc=dvhart@infradead.org \
--cc=hdegoede@redhat.com \
--cc=hpa@zytor.com \
--cc=justinstitt@google.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.travis@hpe.com \
--cc=mingo@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=russ.anderson@hpe.com \
--cc=steve.wahl@hpe.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.