Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Fri, 15 Sep 2023 10:13:32 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Nishanth Menon <nm@ti.com>
Cc:     Justin Stitt <justinstitt@google.com>,
        Tero Kristo <kristo@kernel.org>,
        Santosh Shilimkar <ssantosh@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org
Subject: Re: [PATCH] firmware: ti_sci: refactor deprecated strncpy
Message-ID: <202309151012.446CC82E2@keescook>
References: <20230913-strncpy-drivers-firmware-ti_sci-c-v1-1-740db471110d@google.com>
 <202309142103.6DFFDEB@keescook>
 <20230915124038.vmj3gzthboypzp3v@parsnip>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230915124038.vmj3gzthboypzp3v@parsnip>
Precedence: bulk

On Fri, Sep 15, 2023 at 07:40:38AM -0500, Nishanth Menon wrote:
> On 21:03-20230914, Kees Cook wrote:
> > On Wed, Sep 13, 2023 at 08:23:02PM +0000, Justin Stitt wrote:
> > > `strncpy` is deprecated for use on NUL-terminated destination strings [1].
> > > 
> > > We should prefer more robust and less ambiguous string interfaces.
> > > 
> > > A suitable replacement is `strscpy` [2] due to the fact that it guarantees
> > > NUL-termination on the destination buffer.
> > > 
> > > It does not seem like `ver->firmware_description` requires NUL-padding
> > > (which is a behavior that strncpy provides) but if it does let's opt for
> > > `strscpy_pad()`.
> > > 
> > > Link: https://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>
> > 
> > Looks right to me.
> > 
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> 
> Does this belong to stable as well? If so, please add appropriate stable
> process.

No need. This is a refactoring only. :)

-- 
Kees Cook