Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Fri, 29 Sep 2023 12:56:22 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Dean Luick <dean.luick@cornelisnetworks.com>
Cc:     Leon Romanovsky <leon@kernel.org>,
        Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
        Jason Gunthorpe <jgg@ziepe.ca>,
        Justin Stitt <justinstitt@google.com>,
        linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org
Subject: Re: [PATCH] IB/hfi1: replace deprecated strncpy
Message-ID: <202309291255.C5485E6811@keescook>
References: <20230921-strncpy-drivers-infiniband-hw-hfi1-chip-c-v1-1-37afcf4964d9@google.com>
 <169537858725.3339131.15264681410291677148.b4-ty@kernel.org>
 <2f4bd46c-664e-4253-8d57-16bd46dd3be8@cornelisnetworks.com>
 <202309232019.BE78A9C0@keescook>
 <a3b6e914-7469-42d7-81c8-9775715b263e@cornelisnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a3b6e914-7469-42d7-81c8-9775715b263e@cornelisnetworks.com>
Precedence: bulk

On Tue, Sep 26, 2023 at 07:56:34AM -0500, Dean Luick wrote:
> On 9/23/2023 10:20 PM, Kees Cook wrote:
> > On Fri, Sep 22, 2023 at 09:25:39AM -0500, Dean Luick wrote:
> >> On 9/22/2023 5:29 AM, Leon Romanovsky wrote:
> >>>
> >>> On Thu, 21 Sep 2023 07:17:47 +0000, Justin Stitt wrote:
> >>>> `strncpy` is deprecated for use on NUL-terminated destination strings
> >>>> [1] and as such we should prefer more robust and less ambiguous string
> >>>> interfaces.
> >>>>
> >>>> We see that `buf` is expected to be NUL-terminated based on it's use
> >>>> within a trace event wherein `is_misc_err_name` and `is_various_name`
> >>>> map to `is_name` through `is_table`:
> >>>> | TRACE_EVENT(hfi1_interrupt,
> >>>> |        TP_PROTO(struct hfi1_devdata *dd, const struct is_table *is_entry,
> >>>> |                 int src),
> >>>> |        TP_ARGS(dd, is_entry, src),
> >>>> |        TP_STRUCT__entry(DD_DEV_ENTRY(dd)
> >>>> |                         __array(char, buf, 64)
> >>>> |                         __field(int, src)
> >>>> |                         ),
> >>>> |        TP_fast_assign(DD_DEV_ASSIGN(dd);
> >>>> |                       is_entry->is_name(__entry->buf, 64,
> >>>> |                                         src - is_entry->start);
> >>>> |                       __entry->src = src;
> >>>> |                       ),
> >>>> |        TP_printk("[%s] source: %s [%d]", __get_str(dev), __entry->buf,
> >>>> |                  __entry->src)
> >>>> | );
> >>>>
> >>>> [...]
> >>>
> >>> Applied, thanks!
> >>
> >> It is unfortunate that this and the qib patch was accepted so quickly.  The replacement is functionally correct.  However, I was going to suggest using strscpy() since the return value is never looked at and all use cases only require a NUL-terminated string.  Padding is not needed.
> >
> > Is the trace buffer already guaranteed to be zeroed? Since this is
> > defined as a fixed-size string in the buffer, it made sense to me to be
> > sure that the unused bytes were 0 before copying them to userspace.
> 
> I was not aware that binary trace records were exposed to user space.  If so, and the event records are not zeroed (either the buffer as a whole, or individual records), then strscpy_pad() is the correct solution.  My quick review of the tracing system suggests that nothing is zeroed and the record is embedded in a larger structure.  However, this begs the question for all users of tracing: Aren't alignment holes in the fast assign record a leak?

I thought they were passed over direct to userspace somehow, but I
haven't looked at the details in a long time. I could very well be
misunderstanding it.

-- 
Kees Cook